我们即将使用 JSON 对象作为传输方式来实现 Web 服务。我们打算让第三方组织连接到我们的网络，为此我们计划在未来使用标准化协议来简化集成。
对于 JSON，目前有两种规范：JSON-RPC 和 JSON-WSP。我想知道任何人对这两者的看法，如果你站在我的立场上，你会用什么。现在，我看到 JSON-RPC 已经存在了一段时间，并且已经实现了多种语言。 JSON-WSP 处于早期阶段，但它旨在取代 JSON-RPC（RFC 正在开发中）。我认为从长远来看 JSON-WSP 将是一个很好的解决方案，但我可能错了。
【问题讨论】：
标签： json web-services rest
这两种协议的主要区别在于 JSON-WSP 可以用jsonwsp/description object 来描述它自己的服务方法。如果您希望您的客户端能够“了解”您的 Web 服务，并且可能提供动态客户端用户界面，当您更改服务方法时可以自动更改可视化，这很好。因此，服务器端更新可能会变得非常容易分发。
JSON-WSP 在规范中支持attachments
JSON-RPC 支持批处理方法调用 - 在一个请求中调用多个方法。你也可以做无响应的请求（通知）
JSON-RPC 是两种协议中最古老的一种，因此它有更多的实现和一个庞大的社区。p>
所以我想这一切都归结为您的需求。
如果您正在构建一个基于浏览器的应用程序，JSON-WSP 使用官方 javascript 客户端提供了一种基于 Ajax 的高效机制。 JavaScript json-wsp 客户端解析服务描述并生成一个代理对象，其方法将 1 对 1 映射到 json-wsp 方法：
http://ladonize.org/index.php/Python_Example#JavaScript_JSON-WSP_client
【讨论】：
为什么不使用 REST？
如果您已经知道 JSON 类型的格式，请将它们记录为您的各个资源的表示形式，然后通过 HTTP 提供对它们的访问。这样，您将受益于底层传输基础设施（缓存可能性、强大的工具等）。
在每个资源之间使用超链接以允许客户端在它们之间导航。然后，您的 API 的用户将不会被绑定到基于合约的 RPC 机制，这将使您难以发展，并且需要另一个工具包供您的客户使用。使用 REST 只需要一个 HTTP 库（它们是一毛钱）和一个 JSON 解析器（它们已经需要）。此外，您以后可以随时添加其他编码选项（例如 XML），而对现有客户端的影响最小。
使用 JSON 并不意味着必须在 JSON-RPC 或 JSON-WSP 之间进行选择。使用历史悠久的超级简单标准（如 HTTP 和 JSON）为您的 API 寻找最低共同标准，并充分利用它们。一旦您开始在其中分层更多规范和标准，您会发现 API 的复杂性成比例地增长。
【讨论】：