@iEricLee Creation time : 2023-06-10 11:04:55 Last Modification Time : 2023-06-10 11:04:55
译者注:在微服务架构设计,构建API和服务间通信技术选型时,对 REST 和 gRPC 的理解和应用还存在知识盲区,近期看到国外的这篇文章:A detailed comparison of REST and gRPC,将二者进行了详细对比。周末有时间翻译过来,希望能帮到大家!
很长一段时间以来,REST是构建API的唯一“标准”。近年来,出现了新的替代方案。2015年,脸书发布了GraphQL,2016年谷歌紧随其后发布了gRPC,被广泛使用。在本文中,将关注gRPC,并将其与REST进行比较。
下表将概述本文讨论的要点,并显示 REST 和 gRPC 真正的亮点。
主题 | REST | gRPC |
---|---|---|
标准化 | 无标准 | 定义明确 |
范式 | 以资源为中心 | 以服务方法为中心 |
服务模式 | 一元流 | 一元流、客户端流、服务器流和双向流 |
要求 | 任何 HTTP、Json解析 | 编程语言需要支持 HTTP/2, gRPC |
API 设计 | 代码优先 | 设计优先 |
默认数据格式 | Json | Protobuf |
WEB浏览器支持 | 浏览器本地支持 | gRPC WEB |
工具 | 成熟的工具 | 特定编程语言工具 |
REST 缺点之一是缺乏标准化,与其说 REST 是一个API标准,不如说是一种范式。许多人在谈论它时都有不同的含义。对大多数人来说,术语“REST API”是基于HTTP的JSON API;对于其他规范,REST 可以与某些规范(如:HATEOAS或 JSON: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 需要生成代码(用于创建客户端或服务器存根),因此仅部分编程语言支持,查看编程语言列表。
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 客户端,这是一个巨大的优势。