REST 和 JSON-RPC 是两种常见的 API 设计风格，适用于不同场景。以下是它们的核心区别与适用建议：

‌核心区别‌

• ‌设计哲学‌

  • ‌REST‌：面向‌资源‌，强调“一切皆资源”，通过标准 HTTP 方法（GET/POST/PUT/DELETE）操作资源，URL 表示资源路径。
  • ‌JSON-RPC‌：面向‌动作/过程‌，通过 method 字段指定要调用的函数名，更贴近本地方法调用思维。

• ‌请求格式‌

  • ‌REST‌：

    GET /api/users/123 POST /api/users Content-Type: application/json { "name": "Alice" }

  • ‌JSON-RPC‌：

    { "jsonrpc": "2.0", "method": "getUserProfile", "params": { "id": 123 }, "id": 1 }

• ‌通信协议‌

  • ‌REST‌：严格基于 HTTP，利用 HTTP 状态码、缓存机制（如 ETag）、方法语义。
  • ‌JSON-RPC‌：可运行在 HTTP、TCP、WebSocket 等之上，通常使用 POST + JSON 体，不依赖 HTTP 方法语义。

• ‌性能与效率‌

  • ‌JSON-RPC‌： payload 更轻，支持‌批量请求‌和‌通知‌（无响应），适合高频内部服务通信。
  • ‌REST‌：因包含完整 HTTP 头部，开销较大，但利于缓存、网关代理、监控等。

• ‌适用场景‌

  • ‌REST 更适合‌：
    • 对外公开 API（如 Web、移动应用）
    • 资源 CRUD 操作（如用户、订单管理）
    • 需要缓存、跨平台、易调试的场景
  • ‌JSON-RPC 更适合‌：
    • 微服务间通信
    • 复杂业务动作（如“审核订单”“充值账户”）
    • 需要高性能、批量操作、事件驱动系统

‌选择建议‌

1. ‌优先选 REST 如果‌：

   • API 面向外部开发者或公众
   • 业务以资源为中心（如博客、商品、用户）
   • 希望利用 HTTP 缓存、状态码、工具链（如 Swagger）

2. ‌优先选 JSON-RPC 如果‌：

   • 是内部服务通信（如微服务之间）
   • 需要调用复杂业务方法（非 CRUD）
   • 要求低延迟、高吞吐、支持批量请求

💡 实际案例：Zabbix 使用 JSON-RPC 2.0 过 HTTP，但所有请求都发到同一个 URL（/api_jsonrpc.php），通过 method 字段区分功能 ‌8。这说明 REST 并非唯一选择，尤其在非标准 CRUD 场景下。

‌补充说明‌

• ‌REST 并非必须用 JSON‌：可支持 XML、YAML 等，但 JSON 最常见 ‌10。
• ‌JSON-RPC 可走 HTTP‌：底层常基于 HTTP，但不依赖其语义，本质是 RPC 协议 ‌8。
• ‌混合使用可行‌：部分系统对外用 REST，对内用 JSON-RPC 或 gRPC ‌4。

如需进一步了解规范细节，可参考 JSON-RPC 2.0 官方规范