如果您请求资源，那么RESTful API在设计上更好。如果您请求一些具有大量参数和复杂方法的复杂数据，而不是简单的CRUD，那么RPC是正确的方法。

我认为，一如既往，这取决于……

REST具有广泛的公众支持的巨大优势，这意味着有大量的工具和书籍。如果你需要制作一个API，让来自不同组织的大量消费者使用，那么只有一个原因:它是受欢迎的。作为一种协议，它当然是完全失败的，因为有太多完全不同的方法来将命令映射到URL/动词/响应。

因此，当你编写一个需要与后端对话的单页web应用程序时，我认为REST太复杂了。在这种情况下，你不必担心长期的兼容性，因为应用程序和API可以一起发展。

I once started with REST for a single page web app but the fine grained commands between the web app and the server quickly drove me crazy. Should I encode it as a path parameter? In the body? A query parameter? A header? After the URL/Verb/Response design I then had to code this mess in Javascript, the decoder in Java and then call the actual method. Although there are lots of tools for it, it is really tricky to not get any HTTP semantics in your domain code, which is really bad practice. (Cohesion)

尝试为中等复杂的站点制作一个Swagger/OpenAPI文件，并将其与该文件中描述远程过程的单个Java接口进行比较。复杂性的增长是惊人的。

因此，对于单页web应用程序，我从REST切换到JSON-RPC。aI开发了一个小型库，在服务器上编码Java接口，并将其传送到浏览器。在浏览器中，这为为每个函数返回承诺的应用程序代码创建了一个代理。

同样，REST也有它的地位，因为它很有名，因此得到了很好的支持。认识到底层的无状态资源哲学和层次模型也很重要。然而，这些原则同样可以在RPC模型中使用。JSON RPC工作于HTTP之上，因此它在这方面具有与REST相同的优势。不同之处在于，当您不可避免地遇到这些不能很好地映射到这些原则的函数时，您不必被迫做大量不必要的工作。

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%的情况下应该走的路线。

祝你好运, 迈克

如果您的服务只使用模型和GET/POST/PUT/DELETE模式就能正常工作，那么请使用纯REST。

我同意HTTP最初是为无状态应用程序设计的。

但是对于现代的、更复杂的(!)实时(web)应用程序，你想要使用Websockets(这通常意味着有状态性)，为什么不同时使用呢?基于Websockets的JSON-RPC非常简单，所以你有以下好处:

在每个客户机上进行即时更新(为更新模型定义您自己的服务器到客户机RPC调用) 容易增加复杂性(尝试只使用REST制作Etherpad克隆) 如果你做得对(只添加RPC作为实时的额外功能)，大多数仍然可以使用REST(除非主要功能是聊天或其他)

由于您只是在设计服务器端API，所以从定义REST模型开始，然后根据需要添加JSON-RPC支持，将RPC调用的数量保持在最低限度。

(很抱歉括号用多了)

如果您请求资源，那么RESTful API在设计上更好。如果您请求一些具有大量参数和复杂方法的复杂数据，而不是简单的CRUD，那么RPC是正确的方法。

最好在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.