json-rpc 2.0 协议需实现三部分:序列化/反序列化请求与响应(含必填字段jsonrpc="2.0"、method、params、id)、可靠传输(如http/websocket,需设content-type: application/json)、严格解析响应并校验id与error/result互斥性。

JSON-RPC协议到底要实现哪几部分
JSON-RPC 2.0 不是 HTTP 协议,而是一种消息格式约定。你真正要做的只有三件事:序列化请求/响应、传输(通常走 HTTP 或 WebSocket)、解析返回结果。C++ 里没有原生支持,得靠第三方库补足,jsoncpp 或 nlohmann/json 负责 JSON 编解码,libcurl 或 boost.beast 负责发请求。
容易踩的坑是混淆「协议」和「传输层」——比如以为用 std::string 拼个 JSON 就算实现了 JSON-RPC,结果漏掉 id 字段或没设 Content-Type: application/json,服务端直接返回 Invalid Request。
- 必须带
jsonrpc字段,值固定为"2.0" -
id必须存在,可以是数字、字符串,甚至null(表示通知),但不能缺 - 方法名、参数都放在
method和params字段里,后者支持数组(按序)或对象(按名) - 响应必须严格匹配请求的
id,否则客户端无法关联结果
用 nlohmann/json + libcurl 发一个最简调用
选 nlohmann/json 是因为它 header-only、API 直观;libcurl 胜在跨平台稳定。不用 Boost 或 REST SDK 这类重型依赖,避免编译链过长。
假设后端地址是 http://localhost:8080/rpc,想调 add 方法,传两个整数:
#include <curl>
#include <nlohmann><p>size_t write_callback(void<em> ptr, size_t size, size_t nmemb, std::string</em> s) {
s->append((char<em>)ptr, size </em> nmemb);
return size * nmemb;
}</p>
<p>std::string call_rpc(const std::string& url, const std::string& method, const nlohmann::json& params) {
CURL* curl = curl_easy_init();
std::string response;
if (!curl) return "";</p>
<pre class="brush:php;toolbar:false;">nlohmann::json req = {
{"jsonrpc", "2.0"},
{"method", method},
{"params", params},
{"id", 1} // 简单起见用固定 id,实际应递增或用 uuid
};
std::string json_str = req.dump();
curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, json_str.c_str());
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_callback);
curl_easy_setopt(curl, CURLOPT_WRITEDATA, &response);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, curl_slist_append(nullptr, "Content-Type: application/json"));
CURLcode res = curl_easy_perform(curl);
curl_easy_cleanup(curl);
return res == CURLE_OK ? response : "";
}
调用示例:auto resp = call_rpc("http://localhost:8080/rpc", "add", {1, 2});,得到类似 {"jsonrpc":"2.0","result":3,"id":1} 的字符串。
注意点:
详细的 Three.js 3D 图形参考,涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
-
params传{1, 2}是数组形式;若后端要求命名参数,得写成nlohmann::json{{"a", 1}, {"b", 2}} - 没做超时控制,生产环境必须加
CURLOPT_TIMEOUT - 没检查 HTTP 状态码(如 500),
curl_easy_perform成功只代表网络通,不代表 RPC 成功
怎么安全提取响应里的 result 或 error
别直接用 std::string::find 解析 JSON 响应——字段顺序不保证,result 和 error 是互斥的,且 error 对象里还有 code 和 message 两层嵌套。
用 nlohmann::json 解析后,先确认 json["jsonrpc"] == "2.0",再判断是否存在 error 字段:
nlohmann::json j = nlohmann::json::parse(response);
if (j.is_discarded()) throw std::runtime_error("invalid json");
<p>if (j.contains("error") && !j["error"].is_null()) {
int code = j["error"]["code"];
std::string msg = j["error"]["message"];
// 处理错误,比如 code == -32601 表示 Method not found
} else if (j.contains("result")) {
auto result = j["result"]; // 类型取决于服务端返回,可能是 number、string、object...
// 安全取值:result.get<int>() 或 result.is_number() 等判断后转换
}</int></p>
常见陷阱:
- 直接
j["result"].get<int>()</int>会抛异常,如果服务端返回的是double或null - 忽略
id校验,导致并发调用时结果错配(尤其多线程下) - 把
error当字符串打印,没看code值,错过可重试或需降级的场景
为什么别自己手写 JSON-RPC 客户端类
看起来封装个 RpcClient 类挺干净,但很快会遇到边界问题:id 自增怎么线程安全?批量调用(batch)怎么处理?超时/重试策略放哪?连接池要不要管?
真实项目里,这些不是“锦上添花”,而是刚起步就卡住的点。比如:
- HTTP Keep-Alive 没开,每个请求建新连接,吞吐掉一半
- 没设
CURLOPT_TCP_KEEPALIVE,长连接空闲断连,后续请求失败 - 用
std::map<int std::function>></int>存 callback,但没考虑id冲突或超时清理
建议初期就用现成轻量封装,比如 jsonrpccpp(C++11,含 client/server)或自己只封装核心通信逻辑,其余交给业务层决策。RPC 的复杂性不在 JSON 序列化,而在请求生命周期管理。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!










