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 文檔）[¹][⁴]。