我使用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调用的数量保持在最低限度。

(很抱歉括号用多了)

我已经对这个问题进行了一些详细的研究，并认为纯REST的局限性太大，RPC是最好的，尽管我的大多数应用程序都是CRUD应用程序。如果您坚持使用REST，那么您最终将会挠头思考如何轻松地将另一个所需的方法添加到API中以实现某些特殊目的。在许多情况下，使用REST实现这一点的唯一方法是为它创建另一个控制器，这可能会使程序过于复杂。

如果您决定使用RPC，唯一的区别是您显式地将动词指定为URI的一部分，这是清晰的、一致的、bug较少的，而且确实没有麻烦。特别是如果你要创建一个超越简单CRUD的应用程序，RPC是唯一的选择。我对REST的纯粹主义者还有另一个问题:HTTP POST, GET, PUT, DELETE在HTTP中有明确的含义，这些含义被REST颠覆为其他含义，仅仅是因为它们在大多数时间都适用——但不是所有时间都适用。

在编程中，我很久以前就发现，试图用一件事来表示两件事，有时会让你吃不厌。我喜欢能够对几乎每个操作都使用POST，因为它提供了按方法需要发送和接收数据的自由。你不能把整个世界都放进CRUD里。

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

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

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相同的优势。不同之处在于，当您不可避免地遇到这些不能很好地映射到这些原则的函数时，您不必被迫做大量不必要的工作。

错误的问题:强加一个根本不存在的摩尼教!

您可以使用带有“较少动词”(没有方法)的JSON-RPC，并保留sendo id、参数、错误代码和警告消息所需的最小标准化。JSON-RPC标准没有说“你不能是REST”，只是说如何打包基本信息。

“REST JSON-RPC”存在!是REST与“最佳实践”，最小化信息包装，简单可靠的合同。

例子

(从这个答案和教学上下文)

在处理REST时，从资源的角度考虑通常会有所帮助。在这种情况下，资源不仅仅是“银行账户”，而是该银行账户的交易……但是JSON-RPC没有指定“方法”参数，所有都是由端点的“路径”编码的。

REST Deposit with POST /Bank/Account/John/Transaction with JSON request {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}. The JSON response can be something as {"jsonrpc": "2.0", "result": "sucess", "id": 12} REST Withdraw with POST /Bank/Account/John/Transaction ... similar. ... GET /Bank/Account/John/Transaction/12345@13 ... This could return a JSON record of that exact transaction (e.g. your users generally want a record of debits and credits on their account). Something as {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. The convention about (REST) GET request can include encode of id by "@id", so not need to send any JSON, but still using JSON-RPC in the response pack.