为什么JSON RPC:

对于REST api，我们必须为可能需要的每个功能/方法定义一个控制器。因此，如果我们想让客户端访问10个方法，我们就必须编写10个控制器来将客户端请求连接到特定的方法。

另一个因素是，即使我们为每个方法/功能使用不同的控制器，客户端也必须记住是使用POST还是GET。这使事情更加复杂。为了发送数据，如果使用POST，则必须设置请求的内容类型。

对于JSONRPC，事情大大简化了，因为大多数JSONRPC服务器操作POST HTTP方法，内容类型始终是application/ JSON。这减轻了在客户端使用正确的HTTP方法和内容设置的负担。

不必为服务器想要向客户端公开的不同方法/功能创建单独的控制器。

为什么休息:

对于服务器希望向客户端公开的不同功能，有不同的url。因此，您可以嵌入这些url。

这些观点大多是有争议的，完全取决于一个人的需要。

最好在REST和JSON-RPC之间选择JSON-RPC，为web应用程序开发一个更容易理解的API。JSON-RPC是首选，因为它对方法调用和通信的映射很容易理解。

选择最合适的方法取决于约束条件或主要目标。例如，只要性能是一个主要特征，就建议使用JSON-RPC(例如，高性能计算)。但是，如果主要目标是不可知，以便提供一个通用的接口供其他人推断，则建议使用REST。如果两个目标都需要实现，建议同时包含两个协议。

The fact which actually splits REST from JSON-RPC is that it trails a series of carefully thought out constraints- confirming architectural flexibility. The constraints take in ensuring that the client as well as server are able to grow independently of each other (changes can be made without messing up with the application of client), the calls are stateless (the state is regarded as hypermedia), a uniform interface is offered for interactions, the API is advanced on a layered system (Hall, 2010). JSON-RPC is rapid and easy to consume, however as mentioned resources as well as parameters are tightly coupled and it is likely to depend on verbs (api/addUser, api/deleteUser) using GET/ POST whereas REST delivers loosely coupled resources (api/users) in a HTTP. REST API depends up on several HTTP methods such as GET, PUT, POST, DELETE, PATCH. REST is slightly tougher for inexperienced developers to implement.

JSON (denoted as JavaScript Object Notation) being a lightweight data-interchange format, is easy for humans to read as well as write. It is hassle free for machines to parse and generate. JSON is a text format which is entirely language independent but practices conventions that are acquainted to programmers of the family of languages, consisting of C#, C, C++, Java, Perl, JavaScript, Python, and numerous others. Such properties make JSON a perfect data-interchange language and a better choice to opt for.

REST与HTTP紧密耦合，因此如果您只通过HTTP公开API，那么REST更适合于大多数(但不是所有)情况。然而，如果你需要通过其他传输方式(如消息传递或web套接字)公开你的API，那么REST就不适用了。

根据Richardson成熟度模型，问题不是REST vs. RPC，而是多少REST?

从这个角度来看，REST标准的遵从性可以分为4个级别。

0级:从动作和参数的角度考虑。正如本文所解释的，这在本质上等同于JSON-RPC(本文对XML-RPC进行了解释，但两者的参数相同)。 第一级:从资源的角度考虑。与资源相关的所有内容都属于同一个URL 第2级:使用HTTP动词 第三级:HATEOAS

According to the creator of REST standard, only level 3 services can be called RESTful. However, this is a metric of compliance, not quality. If you just want to call a remote function that does a calculation, it probably makes no sense to have relevant hypermedia links in the response, neither differentiation of behavior based on the HTTP verb used. So, a such call inherently tends to be more RPC-like. However, lower compliance level does not necessarily mean statefulness, or higher coupling. Probably, instead of thinking REST vs. RPC, you should use as much REST as possible, but no more. Do not twist your application just to fit with the RESTful compliance standards.

Great answers - just wanted to clarify on a some of the comments. JSON-RPC is quick and easy to consume, but as mentioned resources and parameters are tightly coupled and it tends to rely on verbs (api/deleteUser, api/addUser) using GET/ POST where-as REST provides loosely coupled resources (api/users) that in a HTTP REST API relies on several HTTP methods (GET, POST, PUT, PATCH, DELETE). REST is slightly harder for inexperienced developers to implement, but the style has become fairly common place now and it provides much more flexibility in the long-run (giving your API a longer life).

除了没有紧密耦合的资源外，REST还允许您避免提交到单一的内容类型中——这意味着如果您的客户端需要接收XML、JSON甚至YAML格式的数据——如果在您的系统中，您可以使用内容类型/接受标头返回其中任何一种。

这让你的API足够灵活，以支持新的内容类型或客户端需求。

But what truly separates REST from JSON-RPC is that it follows a series of carefully thought out constraints- ensuring architectural flexibility. These constraints include ensuring that the client and server are able to evolve independently of each other (you can make changes without messing up your client's application), the calls are stateless (state is represented through hypermedia), a uniform interface is provided for interactions, the API is developed on a layered system, and the response is cacheable by the client. There's also an optional constraint for providing code on demand.

然而，尽管如此，大多数API都不是RESTful的(根据Fielding的说法)，因为它们不包含超媒体(在响应中嵌入超文本链接，帮助导航API)。大多数api都是类似REST的，因为它们遵循大多数REST的概念，但忽略了这个约束。然而，越来越多的api正在实现这一点，它正在成为一种主流实践。

这也为您提供了一些灵活性，因为超媒体驱动的api(如Stormpath)将客户端引导到URI(这意味着如果某些情况发生了变化，在某些情况下您可以修改URI而不会产生负面影响)，而与RPC一样，URI需要是静态的。使用RPC，您还需要广泛地记录这些不同的uri，并解释它们如何相互关联地工作。

一般来说，如果您想要构建一个可扩展的、灵活的、长期存在的API，我认为REST是最佳选择。基于这个原因，我认为这是99%的情况下应该走的路线。

祝你好运, 迈克

在我看来，关键在于行动vs资源导向。REST是面向资源的，非常适合CRUD操作，并且由于其已知的语义为第一个用户提供了一些可预测性，但是当从方法或过程实现时，将迫使您提供对以资源为中心的世界的人工转换。另一方面，RPC非常适合面向操作的api，在这种api中，您公开的是服务，而不是可用于RPC的资源集。

毫无疑问REST更受欢迎，如果你想将API公开给第三方，这无疑会增加一些好处。

如果不是(例如在SPA中创建AJAX前端)，我的选择是RPC。特别是JSON- rpc，结合JSON Schema作为描述语言，并根据用例通过HTTP或Websockets传输。

JSON-RPC是一个简单而优雅的规范，它定义了用于同步或异步RPC的请求和响应JSON有效负载。

JSON Schema是一份规范草案，定义了一种基于JSON的格式，旨在描述JSON数据。通过使用JSON Schema描述您的服务输入和输出消息，您可以在消息结构中拥有任意的复杂性，而不会影响可用性，并且可以自动化服务集成。

传输协议(HTTP vs websockets)的选择取决于不同的因素，最重要的是你是否需要HTTP特性(缓存、重新验证、安全性、幂等性、内容类型、多部分等等)，或者你的应用程序是否需要在高频率下交换消息。

到目前为止，这主要是我个人对这个问题的看法，但是现在有一些东西可以真正帮助那些阅读这些行的Java开发人员，我在过去的一年里一直在工作的框架，诞生于你现在想知道的同一个问题:

http://rpc.brutusin.org

你可以在这里看到一个现场演示，展示了用于功能测试的内置存储库浏览器(感谢JSON Schema)和一系列示例服务:

http://demo.rpc.brutusin.org

希望对伴侣有帮助!

Nacho