我们即将实现一个使用JSON对象作为传输模式的web服务。我们的目的是让第三方组织连接到我们的网络，并且我们计划使用标准化协议来简化未来的集成。JSON-WSP或JSON-RPC
对于JSON，目前有两个规范：JSON-RPC和JSON-WSP。我想知道任何人对这两者的看法，以及如果你在我的鞋子里，你会用什么。现在，我看到JSON-RPC已经存在了一段时间，并且已经实现了多种语言。 JSON-WSP目前处于早期阶段，但它的目标是取代JSON-RPC（RFC正在起作用）。从长远看，JSON-WSP将是一个很好的解决方案，但我可能是错的。
为什么不使用REST？
如果您已经知道JSON类型的格式，请将它们记录为各个资源的表示形式，然后通过HTTP提供对它们的访问。这样，您将获得底层交通基础设施的好处（缓存可能性，优秀工具等）。
使用每个资源之间的超链接来允许客户端在它们之间导航。然后，您的API的用户将不会绑定到基于合同的RPC机制，这对您来说很难发展，并且需要另一个工具包供客户使用。使用REST只需要一个HTTP库（它们是十几美元）和一个JSON解析器（他们已经需要它）。此外，您随后可以添加其他编码选项（如XML），而对现有客户端的影响最小。
使用JSON并不意味着必须在JSON-RPC或JSON-WSP之间进行选择。使用早已建立的，超级简单的标准（如HTTP和JSON）来寻找API的最小公分母，并将它们用于其最佳优势。一旦你开始在那里分层出更多的规格和标准，你会发现API的复杂性成比例增长。
JSON-RPC正如你所描述的那样，但是以指定的形式。您可以通过HTTP进行转换，或者只使用普通的TCP。 – barell
这就是为什么：https://medium.freecodecamp.org/rest-is-the-new-soap-97ff6c09896d –
这两个协议的主要区别在于JSON-WSP可以用jsonwsp/description object来描述它自己的服务方法。如果你希望你的客户能够“知道”你的web服务，并且可能提供一个动态的客户端用户界面，当你改变服务方法时可以自动改变可视化，这很好。因此，服务器端更新可能变得非常容易分发。
JSON-WSP具有在说明书中
JSON-RPC具有用于批处理方法调用支持attachments支持 - 调用几个方法在一个请求。你也可以做响应请求（通知）
JSON-RPC是两个协议中最老的，因此它有更多的实现和一个大的社区。
所以我想这一切都归结为您的需求。
如果您正在构建基于浏览器的应用程序JSON-WSP使用官方JavaScript客户端提供了一种高效的基于Ajax的机制。中的JavaScript JSON-WSP客户端解析服务描述并生成方法映射1对1到JSON-WSP方法代理对象：
http://ladonize.org/index.php/Python_Example#JavaScript_JSON-WSP_client
看到http://blog.stackoverflow.com/2011/08/gorilla-vs-shark/ –