JSON-RPC 2.0 与 1.0 对比总结

---

一、核心特性对比

特性	JSON-RPC 1.0	JSON-RPC 2.0
协议版本标识	无显式版本字段，依赖 method 和参数结构区分[5]。	强制包含 "jsonrpc": "2.0" 字段，明确版本[1][4]。
参数结构	仅支持索引数组（params: [1, 2]）[5]。	支持索引数组或关联数组（params: {"a": 1, "b": 2}）[3][4]。
错误处理	错误信息结构简单，无标准错误码定义[5]。	标准化错误码（如 -32601 表示方法未找到）[2][4]，支持自定义错误码（范围 -32000~-32099）[4]。
批量请求	不支持[5]。	支持批量请求（多个请求打包为数组）[1][4]。
通知机制	无明确支持，需通过无 id 或特殊逻辑实现[5]。	显式支持通知（无 id 字段，无需响应）[3][4]。
兼容性	采用对等（Peer-to-Peer）架构，客户端和服务端均可发起调用[5]。	采用客户端-服务器（Client-Server）架构，明确角色分离[5]。

---

二、使用场景对比

场景	JSON-RPC 1.0	JSON-RPC 2.0
简单 RPC 调用	适用低复杂度、固定参数顺序的调用（如早期区块链接口）[5]。	兼容 1.0 场景，但更推荐用于需要扩展性的场景[4]。
复杂业务逻辑	参数灵活性不足，难以支持命名参数[5]。	支持关联数组参数，适合复杂参数传递（如配置类、多层级数据）[3][4]。
批量操作	需手动拆分多个请求，效率较低[5]。	原生支持批量请求，减少网络开销（如一次性调用多个微服务接口）[1][4]。
事件驱动/通知	需依赖第三方扩展或自定义逻辑实现通知[5]。	内置通知机制，适合推送事件（如服务器主动发送状态更新）[3][4]。

---

三、示例对比

1. 单个请求

JSON-RPC 1.0

{"method": "subtract","params": [42, 23],"id": 1
}

JSON-RPC 2.0

{"jsonrpc": "2.0","method": "subtract","params": [42, 23],"id": 1
}

2. 批量请求

JSON-RPC 1.0
不支持，需拆分为多个独立请求

JSON-RPC 2.0

[{"jsonrpc": "2.0", "method": "sum", "params": [1, 2], "id": "1"},{"jsonrpc": "2.0", "method": "notify_hello", "params": ["Alice"]},{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": "2"}
]

3. 通知（无响应）

JSON-RPC 1.0
需省略 id 或依赖自定义协议

JSON-RPC 2.0

{"jsonrpc": "2.0","method": "updateStatus","params": ["online"]
}

4. 错误响应

JSON-RPC 1.0

{"result": null,"error": {"code": -1, "message": "Method not found"},"id": 1
}

JSON-RPC 2.0

{"jsonrpc": "2.0","error": {"code": -32601,"message": "Method not found","data": {"debug": "Method 'foo' is not defined"}},"id": 1
}

---

四、总结

1. 协议设计

   • 1.0 是早期轻量级方案，适合简单 RPC 调用，但缺乏标准化错误处理和扩展性[⁵]。
   • 2.0 引入版本控制、标准化错误码、批量请求等特性，更适合复杂分布式系统[¹][⁴]。

2. 适用场景

   • 1.0：简单接口、历史兼容场景（如旧版区块链）。
   • 2.0：微服务通信、批量操作、事件驱动系统（如 MCP 协议中的大模型交互）[¹][⁴]。

3. 生态与工具

   • 1.0 工具链较老旧，2.0 支持更多现代开发工具（如 Postman、Swagger 文档）[¹][⁴]。