很长一段时间以来，REST是构建API的唯一“标准”。近年来，出现了新的替代方案。2015年，脸书发布了GraphQL，2016年谷歌紧随其后发布了gRPC，被广泛使用。在本文中，将关注gRPC，并将其与REST进行比较。

概述

下表将概述本文讨论的要点，并显示 REST 和 gRPC 真正的亮点。

标准化

REST 缺点之一是缺乏标准化，与其说 REST 是一个API标准，不如说是一种范式。许多人在谈论它时都有不同的含义。对大多数人来说，术语“REST API”是基于HTTP的JSON API；对于其他规范，REST 可以与某些规范（如：HATEOAS^[2]或 JSON:API^[3]）互换使用。

REST这个术语甚至与HTTP无关。在使用 REST API 时，可能会导致很多混乱。例如，即使没有明确定义，使用者可能会期望某些 REST API 端点的幂等性或可缓存性。

相比之下，gRPC定义得很好。例如，基于 HTTP/2 的gRPC实现非常详细。

基本差异

REST 和 gRPC 的范式并不相同。

REST 一切都以资源为中心，这些资源可以被检索和操作。如果以图书作为示例资源，REST API通常会提供以下端点：

• • GET /books ：检索所有书，可带有筛选和分页结果的参数

• • GET /books/{id} ：检索指定ID书

• • POST /books ：创建书

• • delete /books/{id} ：删除书

大多数基于 HTTP 的 REST API 都遵循这种模式。这很好，但某些情况很难表示为 REST API。例如，如果想创建多本书，而不想为每本书重复调用 POST/books（出于性能、幂等性或其他原因），该怎么办？是否应该创建 POST/books/batch 端点？这还是“RESTful”吗？虽然在技术上容易解决，但开发人员之间经常会进行长时间的讨论。

另一方面，gRPC是一个RPC框架，以服务方法为中心。如果以图书 API为例，使用gRPC，将使用以下方法创建 BookService ：

• • GetBooks()

• • GetBook()

• • createBook()

• • deleteBook()

可以随心所欲地命名这些方法，并设置任何需要的参数。如果现在想添加一个方法来创建多本书，没有什么能阻止我们添加 createBooks() 方法。gRPC 在设计 API 时提供了更多的“自由”，因为有更少的（自我强加的）限制。

服务模式

gRPC 支持四种服务方法：

• • 一元流：发送单个请求，接收单个响应。

• • 服务器流：发送单一请求，接收多个响应。

• • 客户端流：发送多个请求，接收单一响应。

• • 双向流：发送多个请求，接收多个响应。

与只支持一元请求的 REST 相比，gRPC 有一个非常好的优势。在 REST API 中支持其他服务模式需要使用不同的协议，例如：服务器发送的事件或websocket，这不是很“RESTful”。

要求

REST API通常“只适用于”任何类型的 HTTP 版本。只要一种编程语言有一个 HTTP 客户端和一个用于 JSON 解析的库，那么使用 REST API 就轻而易举了。

gRPC 明确需要 HTTP/2 支持，否则它将无法工作。近年来，由于大多数框架都增加了对 HTTP/2 的支持，这已经不再是一个问题了。

由于 gRPC 需要生成代码（用于创建客户端或服务器存根），因此仅部分编程语言支持，查看编程语言列表^[4]。

API 设计

REST API 通常是其实现的结果，称为“代码优先（code-first）”。虽然可以先用 OpenAPI 设计API，然后生成服务器存根，但这不是许多开发人员采用的方法。如果有一个 OpenAPI 定义，那么 OpenAPI 定义很可能是从 API 实现生成的。因此，API定义与实现紧密耦合。模型类的更改可能会导致 API 更改，无意中破坏接口规范。

gRPC 使用不同的方法，在实现API之前必须定义API（称为“设计优先（design-first）”）。然后根据 API 定义生成客户端和服务器存根。这需要提前考虑，因为不能直接实现API。

两种方法各有利弊。通常 REST API 方法允许快速迭代；使用gRPC，在调整 API 实现之前首先更改 API 定义，这可能会很烦人。然而，通过显式定义API更加安全，API变动没那么随意。

数据格式

REST 和 gRPC 都可以使用不同的格式来传输数据。大多数 REST API 使用JSON，而 gRPC 默认使用 Protocol Buffers^[5]，一种轻便高效的结构化数据存储格式，因此我们将比较这两者。

JSON 对数据类型的支持有限，例如，大数字需要表示为字符串。JOSON 是一种文本格式，便于阅读。字段名序列化会占用一些空间。在一些编程语言中，还需要使用反射来反序列化 JSON 消息，速度慢。

如上所述，gRPC API 和相应的消息类型首先被定义为 Protocol Buffers 。每条消息都是强类型的，对于支持的编程语言，可以自动生成代码以（反）序列化消息。由于它是一种二进制格式，并且不序列化字段名，因此它使用的空间比等效的JSON消息少。但是存在缺点：即序列化消息不可读，并且需要 Protobuf 定义来反序列化消息，可能会影响开发人员的体验。

下面的 JSON 示例将占用大约66个字节（去掉空白）。

{
  "persons": [
    {
      "name": "Max",
      "age": 23
    },
    {
      "name": "Mike",
      "age": 52
    }
  ]
}

等效的序列化 protobuf 消息将仅使用19个字节。

0x0A070A034D617810170A080A0448616E731034

大消息

Protobuf 设计用于序列化和反序列化内存中的消息。因此，不建议使用 Protobuf/gRPC 传输巨大的消息。大多数 gRPC 实现对单个消息的默认限制为4MB。

使用 REST API 处理大数据量（例如文件上传）是相当直接的。接收到的文件可以被视为流，只需使用很少的内存。这在 gRPC 中需要更多的操作：文件必须在发送方分为几个部分。然后，每个块将作为单独的消息通过客户端流传输方法发送到服务器。服务器接收每个块，并构造数据流，从而产生与 REST API 类似的行为。

浏览器兼容性

浏览器兼容是 REST 真正的闪光点。它由 WEB 浏览器本地支持，因此可以轻松地使用 WEB应用程序中的 REST API。

gRPC 不直接由浏览器支持，因为它需要明确的 HTTP/2 支持和访问某些 HTTP/2 功能，而 WEB浏览器不提供这些功能。作为一种变通方法，可以使用 gRPC Web 协议，使其可供 WEB 浏览器使用。对于某些编程语言，框架中已经包含了gRPC Web 支持。对于其他场景，需要一个代理来将 gRPC 流转换为 gRPC Web 流，反之亦然。与不需要依赖关系的 REST API 相比，gRPC API 在 WEB 上使用更麻烦。

解决方法可以是使用 JSON 转码，这允许开发人员将 gRPC API 公开为 REST API。

工具

gRPC 和 REST 工具在编程语言和框架之间差异很大。在某些情况下，gRPC 感觉更“原生”，而在另一些情况下，REST 工具则更高级。 对 gRPC 的编程语言支持更为重要，因为需要工具来生成特定编程语言的客户端和服务器存根。对于不受支持的编程语言，不建议使用 gRPC 。

由于 REST API 存在的时间要长得多，因此存在更多有助于构建、测试和部署 REST API 的工具。它们的功能通常比 gRPC 工具更高级。

小结

对于“应该使用 REST 还是 gRPC ？” 没有明确的答案。有些 API 有独特的用例，gRPC 或 REST 可能更适合这些用例。

REST 和 gRPC 都有各自的优点和缺点。

从 WEB 应用程序中使用 REST API 通常更容易。REST也得到了更广泛的使用，这使得开发人员使用它更简单。

gRPC 在服务器到服务器的通信（例如：微服务之间）方面无疑具有优势。能够共享准确的API定义并用多种编程语言创建 API 客户端，这是一个巨大的优势。

引用链接

[1] A detailed comparison of REST and gRPC: https://kreya.app/blog/rest-vs-grpc/
[2] HATEOAS: https://en.wikipedia.org/wiki/HATEOAS
[3] JSON:API: https://jsonapi.org/
[4] 编程语言列表: https://grpc.io/docs/languages/
[5] Protocol Buffers: https://protobuf.dev