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

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

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

首先，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

在我看来，关键在于行动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

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是正确的方法。

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

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

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