REST 和 gRPC 构建 WEB API 详细比较
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
导读 译者注:在微服务架构设计,构建API和服务间通信技术选型时,对 REST 和 gRPC 的理解和应用还存在知识盲区,近期看到国外的这篇文章:A detailed comparison of REST and gRPC[1],将二者进行了详细对比。周末有时间翻译过来,希望能帮到大家! 很长一段时间以来,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通常会提供以下端点:
大多数基于 HTTP 的 REST API 都遵循这种模式。这很好,但某些情况很难表示为 REST API。例如,如果想创建多本书,而不想为每本书重复调用 另一方面,gRPC是一个RPC框架,以服务方法为中心。如果以图书 API为例,使用gRPC,将使用以下方法创建
可以随心所欲地命名这些方法,并设置任何需要的参数。如果现在想添加一个方法来创建多本书,没有什么能阻止我们添加 服务模式gRPC 支持四种服务方法:
与只支持一元请求的 REST 相比,gRPC 有一个非常好的优势。在 REST API 中支持其他服务模式需要使用不同的协议,例如:服务器发送的事件或 要求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个字节(去掉空白)。
等效的序列化 protobuf 消息将仅使用19个字节。 0x0A070A034D617810170A080A0448616E731034 大消息Protobuf 设计用于序列化和反序列化内存中的消息。因此,不建议使用 Protobuf/gRPC 传输巨大的消息。大多数 gRPC 实现对单个消息的默认限制为 使用 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 客户端,这是一个巨大的优势。 引用链接
该文章在 2023/6/14 9:39:37 编辑过 |
关键字查询
相关文章
正在查询... |