了解 HTTP 应用程序接口的 RPC 与 REST

了解 REST 和 RPC 之间的区别对您规划新的 API 非常有用，对您为现有 API 开发功能也非常有帮助。最好不要在单个 API 中混用两种风格，因为这可能会让 API 的用户以及任何工具感到困惑，因为这些工具期待的是一套约定（例如 REST），而当它看到的是另一套约定（RPC）时就会崩溃。在合理的情况下使用 REST，或者在更合适的情况下使用 RPC。或者两者兼用，两全其美！

在过去几年中，每当有人想开始构建 HTTP API 时，他们几乎都会将 REST 作为首选架构风格，而不是 XML-RPC、SOAP 和 JSON-RPC 等其他方法。许多人认为 REST 最终优于其他 "基于 RPC "的方法，这有点误导，因为它们只是不同而已。

本文将在构建 HTTP API 的背景下讨论这两种方法，因为这是它们最常用的方式。RPC 和 REST 都可以通过 AMQP 等其他传输协议使用，但这完全是另一个话题。

REST 是 Roy Fielding 在其论文中描述的 "表征状态传输 "的缩写。遗憾的是，这篇论文并没有被广泛阅读，因此很多人对 REST 都有自己的理解，导致了很多混乱和分歧。REST 是一种客户端与服务器端的关系，服务器端的数据通过简单格式（通常是 JSON 和 XML）的数据表示来提供。这些数据表示为资源或资源集合，然后可对其进行修改，其操作和关系可通过一种称为超媒体的方法来发现。超媒体是 REST 的基础，本质上只是提供链接到其他资源的概念。

除了超媒体之外，还有其他一些限制，例如

REST 必须是无状态的：不会在请求之间持续会话。

响应应声明可缓存性：如果客户遵守规则，将有助于扩展应用程序接口。

REST 注重统一性：如果使用 HTTP，就应尽可能利用 HTTP 的特性，而不是发明约定俗成的东西。

这些限制（还有其他一些限制）使得 REST 架构可以帮助应用程序接口持续使用几十年，而不仅仅是几年。

在 REST 开始流行之前（在 Twitter 和 Facebook 等公司将其 API 标为 REST 之后），大多数 API 都是使用 XML-RPC 或 SOAP 构建的。XML-RPC 存在很多问题，因为确保 XML 有效载荷的数据类型非常困难。在 XML 中，很多东西都只是字符串，因此需要在上面添加元数据，以便描述哪些字段对应哪些数据类型。这也是 SOAP（简单对象访问协议）的基础之一。XML-RPC 和 SOAP 以及定制的自制解决方案在 API 领域占据了很长一段时间，它们都是基于 RPC 的 HTTP API。

RPC "的意思是 "远程过程调用"，本质上与调用 JavaScript、PHP、Python 等语言中的函数一样，都是使用方法名和参数。鉴于 XML 并非每个人都喜欢，RPC API 可以使用 JSON-RPC 协议，也可以像 Slack 的 Web API 一样，定制一个基于 JSON 的 API。

在更简单的 JSON 应用程序接口中，它可能看起来更像这样：

尽管这种有效载荷要简单得多，但我们仍然需要为 getAdUnitsByStatement 和 getAdUnitsBySomethingElse 提供不同的方法。当你看到这样的示例时，REST 很快就开始变得 "更好 "了，因为它允许将通用端点与查询字符串项相结合（例如，GET /ads?statement={foo} 或 GET /ads?something={bar} ）。你可以将查询字符串项组合起来，得到 GET /ads?statement={foo}&limit=500 的结果，从而很快摆脱了作为参数发送的奇怪的 SQL 式语法。

到目前为止，REST 看起来更胜一筹，但这只是因为这些示例使用 RPC 来处理一些 REST 更擅长处理的问题。本文并不试图概括哪种方法 "更好"，而是帮助您做出明智的决定，以确定哪种方法更适合您。

它们有什么用？#

基于 RPC 的 API 适用于操作（即程序或命令）。

基于 REST 的应用程序接口非常适合对领域（即资源或实体）进行建模，使 CRUD（创建、读取、更新、删除）适用于所有数据。

REST 不仅仅是 CRUD，但主要通过基于 CRUD 的操作来完成。REST 将使用 HTTP 方法，如 GET、POST、PUT、DELETE、OPTIONS 和 PATCH（希望还有 PATCH），为正在进行的操作的意图提供语义。

然而，RPC 不会这样做。大多数情况下，RPC API 只使用 GET 和 POST，其中 GET 用于获取信息，POST 用于其他所有操作。常见的 RPC API 使用 POST /deleteFoo，主体为 { "id"： 1 }，而不是 REST 方法，即 DELETE /foos/1。

这并不是什么重要的区别，只是一个实现细节而已。在我看来，最大的区别在于如何处理操作。在 RPC 中，你只需 POST /doWhateverThingNow 即可，这一点非常明确。但在 REST 中，使用这些类似 CRUD 的操作会让你觉得 REST 除了 CRUD 之外，并不擅长处理其他操作。

其实，情况并非完全如此。两种方法都可以触发操作；但在 REST 中，触发更像是一种后效。例如，如果您想向用户 "发送一条消息"，RPC 方法就是这样：

本文标签： # api认证