我过去一直是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

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方面还有更多的区别和优势。

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

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

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

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

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

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

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

(很抱歉括号用多了)

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