REST对JSON-RPC？

Question

我试图在REST和JSON之间进行选择，以便为web应用程序开发API。他们怎么比较？

Update 2015:我发现REST对于Web/HTTP上服务的API更容易开发和使用，因为API可以利用客户机和服务器都理解的现有成熟HTTP协议。例如，响应代码、头、查询、post主体、缓存和许多其他特性可以被API使用，而无需任何额外的工作或设置。

Answer 1

RPC的基本问题是耦合。RPC客户端以多种方式与服务实现紧密耦合，很难在不中断客户端的情况下更改服务实现：

• 客户必须知道程序名称；
• 过程参数顺序、类型和计数事项。更改过程签名(参数的数量、参数的顺序、参数类型等)并不容易.在服务器端，不中断客户端的实现；
• RPC样式只公开过程端点+过程参数。客户不可能确定下一步可以做什么。

另一方面，在REST风格中，很容易通过在表示中包含控制信息(HTTP头+表示)来指导客户端。例如：

• 可以(实际上也是强制性的)嵌入带有链接关系类型的链接，这些链接类型传达了这些URI的含义；
• 客户端实现不需要依赖于特定的过程名称和参数。相反，客户端依赖于消息格式。这为将已经实现的库用于特定的媒体格式(例如Atom、HTML、Collection+JSON、HAL等)提供了可能性。
• 可以轻松地更改URI而不中断客户端，因为它们只依赖于注册的(或特定域的)链接关系；
• 在表示中嵌入类似表单的结构是可能的，如果最终用户是人，客户端就可以将这些描述公开为UI功能；
• 对缓存的支持是额外的优势；
• 标准化状态代码；

在其他方面有更多的差异和优势。

Answer 2

我已经详细地探讨了这个问题，并认为纯粹的REST太有限了，RPC是最好的，尽管我的大多数应用程序都是CRUD应用程序。如果您坚持休息，您最终会绞尽脑汁，不知道如何才能轻松地将另一个所需的方法添加到您的API中，以达到某种特殊的目的。在许多情况下，使用REST的唯一方法是为其创建另一个控制器，这可能会使您的程序过于复杂。

如果您决定使用RPC，唯一的区别是您显式地将谓词指定为URI的一部分，这是明确的、一致的、较少错误的，而且实际上没有麻烦。特别是如果您创建的应用程序远远超出了简单的CRUD，RPC是唯一的方法。对于RESTful纯粹主义者，我还有另一个问题: HTTP、GET、PUT、DELETE在HTTP中有明确的含义，REST将其颠覆为其他事物，仅仅是因为它们大部分时间都适合--但不是所有时间。

在编程中，我很久以前就发现，试图用一件事来表达两件事，总有一天会来咬你的。我喜欢在几乎每一个动作中使用POST，因为它提供了发送和接收数据的自由，就像您的方法所需要的那样。你不能把整个世界都放进垃圾堆里。

Answer 3

首先，HTTP是一种“表示状态传输”架构。这意味着许多有趣的事情：

• 您的API将是无状态的，因此更容易设计(实际上很容易忘记复杂自动机中的转换)，并与独立的软件部分集成。
• 您将被引导将读取方法设计为安全的方法，这将很容易缓存和集成。
• 您将被引导将写入方法设计为幂等方法，这将更好地处理超时问题。

第二，HTTP-REST完全兼容HTTP (见上一部分中的“安全”和“幂等”)，因此您将能够重用HTTP库(为现有的每种语言存在)和HTTP反向代理，这将使您能够实现高级特性(缓存、身份验证、压缩、重定向、重写、日志记录等)。零行代码。

最后但并非最不重要的是，使用HTTP作为RPC协议是一个巨大的错误，根据HTTP1.1的设计者(和REST的发明者)：2