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

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

根据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的局限性太大，RPC是最好的，尽管我的大多数应用程序都是CRUD应用程序。如果您坚持使用REST，那么您最终将会挠头思考如何轻松地将另一个所需的方法添加到API中以实现某些特殊目的。在许多情况下，使用REST实现这一点的唯一方法是为它创建另一个控制器，这可能会使程序过于复杂。

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

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

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

我过去一直是REST的忠实粉丝，它在纸上比RPC有很多优势。你可以给客户端提供不同的内容类型、缓存、HTTP状态代码的重用，你可以通过API引导客户端，如果API不是大部分都是自解释的，你可以在API中嵌入文档。

But my experience has been that in practice this doesn't hold up and instead you do a lot of unnecessary work to get everything right. Also the HTTP status codes often don't map to your domain logic exactly and using them in your context often feels a bit forced. But the worst thing about REST in my opinion is that you spend a lot of time to design your resources and the interactions they allow. And whenever you do some major additions to your API you hope you find a good solution to add the new functionality and you didn't design yourself into a corner already.

This often feels like a waste of time to me because most of the time I already have a perfectly fine and obvious idea about how to model an API as a set of remote procedure calls. And if I have gone through all this effort to model my problem inside the constraints of REST the next problem is how to call it from the client? Our programs are based on calling procedures so building a good RPC client library is easy, building a good REST client library not so much and in most cases you will just map back from your REST API on the server to a set of procedures in your client library.

正因为如此，今天对我来说，RPC感觉更简单、更自然。不过，我真正怀念的是一个一致的框架，它可以很容易地编写自描述和可互操作的RPC服务。因此，我创建了自己的项目，尝试新的方法使RPC对我自己更容易，也许其他人也会发现它有用:https://github.com/aheck/reflectrpc

首先，HTTP-REST是一种“具象状态传输”体系结构。这意味着很多有趣的事情:

您的API将是无状态的，因此更容易设计(在复杂的自动机中很容易忘记转换)，并与独立的软件部件集成。 你将被引导设计安全的读取方法，这将是容易缓存和集成。 你会被引导把写方法设计成幂等的方法，这样可以更好地处理超时。

其次，HTTP- rest完全兼容HTTP(请参阅前一部分中的“安全”和“幂等”)，因此您将能够重用HTTP库(适用于所有现有语言)和HTTP反向代理，这将使您能够实现高级功能(缓存、身份验证、压缩、重定向、重写、日志记录等)，而无需代码行。

最后但并非最不重要的是，根据HTTP 1.1的设计者(以及REST的发明者)的说法，使用HTTP作为RPC协议是一个巨大的错误:http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2