JSON-RPC 2.0 与 1.0 对比总结
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.0 是早期轻量级方案，适合简单 RPC 调用，但缺乏标准化错误处理和扩展性[5]。
- 2.0 引入版本控制、标准化错误码、批量请求等特性，更适合复杂分布式系统[1][4]。
-
适用场景
- 1.0：简单接口、历史兼容场景（如旧版区块链）。
- 2.0：微服务通信、批量操作、事件驱动系统（如 MCP 协议中的大模型交互）[1][4]。
-
生态与工具
- 1.0 工具链较老旧，2.0 支持更多现代开发工具（如 Postman、Swagger 文档）[1][4]。