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

祝你好运, 迈克

根据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.

RPC的基本问题是耦合。RPC客户端以多种方式与服务实现紧密耦合，在不破坏客户端的情况下更改服务实现变得非常困难:

客户需要知道过程名称; 程序参数顺序，类型和计数事项。在不破坏客户端实现的情况下，在服务器端改变过程签名(参数的数量、参数的顺序、参数类型等)并不是那么容易的; RPC样式只公开过程端点+过程参数。客户不可能决定下一步该做什么。

另一方面，在REST风格中，通过在表示(HTTP报头+表示)中包含控制信息来引导客户端是非常容易的。例如:

It's possible (and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs; Client implementations do not need to depend on particular procedure names and arguments. Instead, clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats (e.g. Atom, HTML, Collection+JSON, HAL etc...) It's possible to easily change URIs without breaking clients as far as they only depend on registered (or domain specific) link relations; It's possible to embed form-like structures in representations, giving clients the possibility to expose these descriptions as UI capabilities if the end user is human; Support for caching is additional advantage; Standardised status codes;

在REST方面还有更多的区别和优势。

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

我使用vdata为RPC协议: http://vdata.dekuan.org/

1、PHP和JavaScript都没问题。 2、跨源资源共享(CORS)呼叫仍然正常。

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

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

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

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

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

(很抱歉括号用多了)