JSON-WSP 或 JSON-RPC
我们即将使用 JSON 对象作为传输方式来实现 Web 服务。我们打算让第三方组织连接到我们的网络，为此我们计划使用标准化协议来简化未来的集成。
对于 JSON，目前有两种规范：JSON-RPC 和 JSON-WSP。我想知道任何人对这两者的看法，以及如果您处于我的立场，您会使用什么。目前，我发现 JSON-RPC 已经存在了一段时间并且具有多种语言的实现。 JSON-WSP 尚处于早期阶段，但其目标是取代 JSON-RPC（RFC 正在制定中）。我认为从长远来看 JSON-WSP 将是一个很好的解决方案，但我可能是错的。
We're about to implement a webservice using JSON objects as the mode of transportation. We have an intent of having third-party organizations to connect to our network and for that we are planning to use a standarized protocol to ease integration in the future.
For JSON, there's two specifications at the moment: JSON-RPC and JSON-WSP. I would like to know about anyone's view between these two and what would you use if you're in my shoes. For now, I see that JSON-RPC has been around for a while and has implementations to multiple languages. JSON-WSP is at its early stages but it aims to supersede JSON-RPC (an RFC is in the works). I see that JSON-WSP will be a good solution in the long run but I might be wrong.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这两个协议之间的主要区别在于 JSON-WSP 可以使用 jsonwsp 描述它自己的服务方法/描述对象。如果您希望您的客户端能够“了解”您的 Web 服务，并且可能提供一个动态客户端用户界面，该界面可以在您更改服务方法时自动更改可视化效果，那么这很好。因此，服务器端更新可能会变得非常容易分发。
JSON-WSP 支持规范中的 附件
JSON-RPC 支持批处理方法调用 - 在一个请求中调用多个方法。您还可以执行无响应请求（通知）
JSON-RPC 是这两个协议中最古老的，因此它有更多的实现和一个大型社区。
所以我想这一切都归结为您的需求是什么。
如果您正在构建基于浏览器的应用程序，JSON-WSP 使用官方 JavaScript 客户端提供高效的基于 Ajax 的机制。 JavaScript json-wsp 客户端解析服务描述并生成一个代理对象，其方法与 json-wsp 方法一对一映射：
http://ladonize.org/index.php/Python_Example#JavaScript_JSON-WSP_client
The main difference between the two protocols is that JSON-WSP can describe it's own service methods with the jsonwsp/description object. This is nice if you want your client to be able to "know" your webservices and maybe offer a dynamic client-side user-interface that can change visualisation automatically when you change the service methods. So server-side updates can potentially become very easy to distribute.
JSON-WSP has support for attachments in the specification
JSON-RPC has support for batch-method invocation - invoke several method in one request. Also you can do response-less requests (Notifications)
JSON-RPC is the oldest of the two protocols and therefore it has more implementations and a large community.
So I guess it all boils down to what your needs are.
If you are building a browser-based application JSON-WSP offers an efficient Ajax-based mechanism using the official javascript client. The JavaScript json-wsp client parses the service description and generates a proxy object with methods mapping 1-to-1 to the json-wsp methods:
http://ladonize.org/index.php/Python_Example#JavaScript_JSON-WSP_client
为什么不使用休息？
如果您已经知道 JSON 类型的格式，请将其记录为各个资源的表示形式，然后通过 HTTP 提供对它们的访问。这样，您将受益于底层传输基础设施（缓存可能性、出色的工具等）。
在每个资源之间使用超链接以允许客户端在它们之间导航。这样，您的 API 的用户就不会受到基于合约的 RPC 机制的束缚，这对您来说很难发展，并且需要另一个工具包供您的客户使用。使用 REST 只需要一个 HTTP 库（它们一毛钱一打）和一个 JSON 解析器（它们已经需要）。此外，您以后随时可以添加其他编码选项（例如 XML），而对现有客户端的影响最小。
使用 JSON 并不意味着必须在 JSON-RPC 或 JSON-WSP 之间进行选择。使用长期建立的、超级简单的标准（例如 HTTP 和 JSON）来为您的 API 寻找最低公分母，并充分利用它们。一旦您开始在其中分层更多的规范和标准，您就会发现 API 的复杂性成比例增长。
Why not use REST?
If you already know the format of your JSON types, document those as the representations of your individual resources and then offer access to them via HTTP. That way, you'll get the benefit of the underlying transport infrastructure (caching possibilities, great tooling, etc).
Use hyperlinks between each resource to allow the clients to navigate between them. The users of your API then won't be tied to a contract-based RPC mechanism which will be hard for you to evolve and requires yet another toolkit for your clients to use. Using REST will require only an HTTP library (they are a dime a dozen) and a JSON parser (which they already need). In addition, you could always later add other encoding options (say, XML) with minimal impact to your existing clients.
Using JSON does not mean having to choose between JSON-RPC or JSON-WSP. Go for the lowest common denominators for your API with long-established, uber-simple standards (like HTTP and JSON) and use them to their best advantage. Once you start layering more specs and standards in there, you'll find that the complexity of your API grows proportionally.