害！别提了我上周刚被MindX2的WebSocket通信卡了三天三夜——不是连不上就是推消息延迟半天,整个人暴躁到想摔键盘。直到偶然翻到JSON-RPC这玩意儿,瞬间感觉像被人浇了盆冷水又泼了杯冰可乐:妈耶这才是解决问题的正确姿势啊！这不刚把它塞进gort项目当通信底座,赶紧来跟你们唠唠这个被低估的好东西。

咱别搞那些文绉绉的定义哈: JSON-RPC就是「远程叫函数」的极简协议——客户端想让服务器干个活,不用搞复杂的HTTP GET/POST套路由,直接丢个带"方法名+参数"的JSON过去;服务器干完活把结果也打包成JSON扔回来,完事儿。

听起来像RESTful？但本质差远了: REST是「操作资源」, JSON-RPC是「调用行为」这种)——你要是给后台系统写内部接口,或者搞实时推送,它比REST爽一百倍,比gRPC轻一万倍,懂吧？

对了它还是跨语言跨环境的——Python写服务端,C++写客户端,JavaScript写Web端,只要dou遵循规范,就Neng无缝对接,这点对混多种技术栈的项目来说简直是救星!

JSON-RPC的规范也就千把字,但所有Neng力dou绕不开这三个角色:

客户端发请求必带三个字段:

"jsonrpc": "2.0": 版本号死记硬背就行,少一个小数点dou不行;

"method": 要调用的方法名,字符串类型;

"id": 请求编号,相当于「快递单号」——服务器回复的时候必须原样带回来,不然客户端分不清哪个结果对应哪个请求;

"params": 参数,Ke以是数组或者对象——推荐用对象!万一以后方法加参数,旧客户端不用改代码也Neng兼容!

举个接地气例子: 客户端想让服务器算1+1:

{
  "jsonrpc": "2.0",
  "method": "add",
  "params": {"a": 1, "b": 1},
  "id": "request_123"
}

"id"Ke以是数字也Ke以是字符串,随便你喜欢~只要唯一就行!