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

概述

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

标准化

REST 缺点之一是缺乏标准化,与其说 REST 是一个API标准,不如说是一种范式。许多人在谈论它时都有不同的含义。对大多数人来说,术语“REST API”是基于HTTP的JSON API;对于其他规范,REST 可以与某些规范(如:HATEOASJSON:API)互换使用。

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 需要生成代码(用于创建客户端或服务器存根),因此仅部分编程语言支持,查看编程语言列表

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,一种轻便高效的结构化数据存储格式,因此我们将比较这两者。

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 客户端,这是一个巨大的优势。

dotNET兄弟会-公众号

专注.Net开源技术及跨平台开发!致力于构建完善的.Net开发技术文库!为.Net爱好者提供学习交流家园!

翻译:REST 和 gRPC 详细比较-LMLPHP

06-10 20:37