REST API 与 gRPC API：主要区别解析

API规定了不同软件组件应如何进行交互和通信，它们是使用架构模型（如REST）实现独立系统组件之间数据交换的“粘合剂”。在微服务架构中，API充当了用不同编程语言编写的系统组件之间的“联络人”。这些组件需要一个接口来进行通信，这个接口就是API。

API不仅是微服务的接口，它们还是具有类似于标准软件生命周期的独立功能单元。

API架构风格有很多种。本文将讨论两种流行架构风格：REST API 和 gRPC API 之间的异同。我们将探讨它们的优势、劣势以及潜在的应用场景。

什么是API架构风格？

API架构风格是构建API的模型或一组规则。REST和gRPC是根据不同的架构原则来约束API设计的API架构。例如，REST API必须遵循诸如客户端-服务器分离、无状态性和可缓存性等REST原则。gRPC API必须是通用的、高性能的、与有效负载无关的，并支持多路复用流。总而言之，RESTful API遵循REST架构标准和实践，而gRPC API则遵循gRPC标准。

架构风格定义了客户端与API服务器之间的交互方式。换句话说，它们决定了客户端如何访问和操作API所暴露的数据。架构风格决定了客户端如何构建请求，以及可以发送哪些参数来影响服务器响应。它们告诉客户端，基于特定输入，可以从API期望得到什么样的响应。最后，它们决定了通信模式、通信协议、负载格式以及API暴露的实体（数据对象与过程）。

什么是REST API？

REST API使用HTTP 1.1协议进行数据传输。一个REST API是一个Web服务，因为它使用HTTP协议来传输消息。Web服务处理客户端应用程序与API服务器之间的交互。使用此协议，客户端向API服务器发送一个请求数据的HTTP请求，然后服务器将一个包含编码数据的HTTP响应发送回客户端。

REST API使用的HTTP协议允许用不同编程语言编写的平台和系统相互交互。例如，用Python编写的客户端应用程序可以与用Java编写的API服务器交互。系统之间的这种互操作性使得Web服务在现代软件开发中非常流行——尤其是REST API。

REST对客户端和服务器关注点的分离使其对许多项目具有吸引力，包括移动和Web开发。特别是，它的功能非常适合云应用程序、云计算和微服务。

以下是发送REST API请求的步骤：

决定调用哪个资源URL * 计算要使用的参数值（如果有） * 使用第三方工具将请求翻译成客户端编程语言

什么是 gRPC API？

gRPC 中的“RPC”代表远程过程调用模型。gRPC 中的“g”代表谷歌。因此，gRPC 是谷歌对 RPC 的实现。谷歌创建了 gRPC 的一个变体，以促进微服务之间的快速通信。原始的 RPC 大部分已被 gRPC 取代。

客户端访问和操作 gRPC API 暴露数据的方式与 REST API 不同。REST 允许客户端使用资源 URL 访问“数据对象”。在 REST 中，以资源形式存在的数据是核心和焦点。API 如何处理请求并发回数据对客户端是隐藏的。

相比之下，gRPC 允许客户端访问操作数据的 API“过程”。过程是对数据采取的操作。而数据本身，与 REST API 资源不同，是隐藏的。

以下是构建 gRPC 请求的步骤：

• 
  决定调用哪个过程 * 计算要使用的参数值（如果有） * 使用代码生成的存根进行调用

在上述过程中，您会注意到调用的是过程而不是资源 URL。与 REST 不同，向 gRPC API 发送请求的客户端不需要第三方工具来转换消息。相反，客户端使用由 gRPC 软件生成的代码存根。

REST API 和 gRPC 有什么区别？

以下是 REST 和 gRPC 架构风格之间的一些区别。

API 公开的实体

如前所述，REST 向客户端公开资源 URL 以访问 API，而 gRPC 则公开过程。发送 REST API 调用更为简便，您可以直接在浏览器中输入资源 URL，使用 cURL 向 API 发出命令，或从终端运行脚本。另一方面，gRPC 要求客户端和服务器分别使用 gRPC 软件来发送和接收请求。此外，客户端和服务器必须将 gRPC 生成的代码集成到其构建过程中。

HTTP 1.1 与 HTTP 2.0

REST API 使用 HTTP 1.1 通信，而 gRPC 使用 HTTP 2.0 协议。

当向 REST API 发送请求时，显然您正在使用 HTTP 协议，因为您的请求被发送到一个资源 URL。资源 URL 看起来非常类似于您在网络浏览器中输入以访问网站的 URL。当您在浏览器中查看网站 URL 时，您会注意到网站地址前有 https://。这个字符串表示用于访问网站的协议是 超文本传输协议安全。网络浏览器充当客户端，向服务器发送 API 请求以返回网站的 HTML、JavaScript 和 CSS。

向 REST API 发送请求时，发生相同的过程。HTTP 传输细节（资源 URL）对客户端是可见的，并用于发送请求。REST API 设计者还可以控制资源 URL 的结构。HTTP 1.1 API 的另一个好处是，客户端和服务器可以使用比 gRPC API 提供的技术更广泛可用的网络技术。

gRPC 使用 HTTP，但客户端和服务器从不会看到 gRPC 请求如何映射到 HTTP 协议。这是因为 gRPC 模型是分层在 HTTP 之上的。gRPC 已经决定了 API 请求如何映射到 HTTP 请求，并且不会暴露这些信息。客户端无需担心请求如何映射到 HTTP。相反，客户端遵循定义的发送 gRPC 消息的标准，而不是直接发送 HTTP 请求。与 REST 不同，API 设计者无法访问 HTTP 传输细节。

客户端-服务器通信模型

对于 REST 来说，HTTP 1.1 只能处理一元流。这种流涉及客户端一次发送一个请求，服务器发送一个响应。

对于 gRPC，HTTP 2.0 允许以下流式选项：

• 一元流 – 与 HTTP 1.1 相同。
• 服务器流 – 服务器可以针对客户端发送的单个请求发回多条消息。最后一条消息表示传输已完成。
• 客户端流 – 一个客户端可以同时向服务器发送多条消息。服务器以一个响应进行回复。
• 双向流 – 服务器可以同时处理来自多个客户端的多个请求，并同时发回多个响应。在这种流式传输形式中，客户端和服务器同时发送消息。由客户端负责结束流。

💛🧡🧡客户评价：Baklib能轻松应对跨多个内部整合和管理大量SOP业务线的挑战。作为高级UX设计师和项目经理在监督几个迁移项目时，我发现该平台的易用性和定制功能非常有价值。它简化了设置知识库，以及发布站点的繁琐，以便更轻松地导入和/或编写和设计标准操作程序。这为我们节省了很多时间。能够导入现有文档且完全自定义KB非常棒。最后，用户权限功能是非常适合协作，允许多个利益相关者做出贡献直接而高效。它使我的工作变得更加轻松，并确保平稳而有序的迁移过程。

有效负载

REST 使用 JSON 作为主要消息格式，它是人类可读的，并且不遵循严格的结构。

与 REST JSON 消息不同，gRPC 消息不是人类可读的。这是因为 gRPC 会序列化消息有效负载并对它们进行压缩。由于 gRPC 消息是序列化的，因此它们可以比 JSON 传输得更快。

代码生成

REST API 客户端依赖第三方工具将消息转换为相应的编程语言。当 API 服务器收到请求时，必须将其转换为服务器的编程语言。

在 gRPC 中，客户端不需要第三方工具来转换消息。相反，客户端使用 gRPC 软件生成的存根代码。在服务器端，gRPC 内置了将消息转换为服务器编程语言的功能。

REST 与 gRPC 特性比较

现在我们将比较 REST 和 gRPC 的特性。

特性 REST gRPC 暴露的实体 资源 URL - HTTP 传输细节暴露给客户端和服务器。 过程 - HTTP 映射对客户端和服务器隐藏。 HTTP 协议 HTTP 1.1 - 仅支持单向流。 HTTP 2.0 - 支持双向流，但与 HTTP 1.0 相比浏览器兼容性较差。 浏览器支持 REST 使用 HTTP 1.0 和 JSON 消息格式，因此具有普遍的浏览器支持。 gRPC 的浏览器支持较少，因为它需要一个代理层和 gRPC-web 来在 HTTP 1.1 和 HTTP 2.0 之间来回转换。 负载格式 JSON - 一种人类可读的格式，需要序列化并转换为客户端和服务器的编程语言。JSON 负载也比 gRPC 负载大，导致传输速度比 gRPC 负载慢。

JSON 很灵活，因为它不需要遵循严格的结构。

REST 还支持其他消息格式，如 XML、HTML 和 YAML。 Protobuf 消息格式 - gRPC 使用协议缓冲区对负载进行序列化和压缩，从而减小文件大小。因此，它们可以比 JSON 负载更快地传输。 代码生成 REST 没有内置的代码生成。相反，您必须使用第三方服务来生成 API 请求的代码。

在服务器端，API 请求必须转换为服务器的编程语言。 gRPC 具有内置的代码生成功能，并使用编译器来转换编程语言。 爬取 API 应用程序可以像网络浏览器爬取网页一样轻松地爬取整个 REST API，因为与 gRPC 不同，它不需要元数据。 每个实体（相当于 REST 中的资源）属于一个单独的 API，需要专门的工具或方法来爬取。 可缓存性虽然REST API不直接处理缓存，但客户端可以有效缓存HTTP响应。缓存之所以可能，是因为REST通过URL分离端点，并利用HTTP标头执行CRUD操作。gRPC API请求使用POST方法发送，该方法不可缓存。 部分更新机制Open API规范允许使用PATCH方法来更新资源。gRPC不提供此类方法。 实现由于第三方工具广泛可用，可以实现快速实施。由于缺乏快速构建服务的可用工具，gRPC API的实现速度较慢。gRPC不如REST流行或历史悠久，因此可用工具较少。

何时使用REST与gRPC？

REST和gRPC的特性使其适用于不同的用例。

最适合公共Web服务：REST

REST的特性非常适合公共Web服务API。REST使用HTTP 1.1协议，该协议得到浏览器的普遍支持。相比之下，gRPC的兼容性较差，因为它使用HTTP 2.0。虽然gRPC的有效载荷较小，但REST的主要有效载荷格式JSON更灵活且对浏览器更友好。REST还允许您使用其他消息格式，如HTML、纯文本、XML和YAML，这增加了其灵活性。

最适合内部API、物联网和移动应用：gRPC

gRPC的特性使其适合内部API、物联网和移动开发。这些应用受益于gRPC的双向流、小有效载荷大小和内置代码生成功能。对于这些应用，gRPC的小消息尺寸使其比REST更具性能和可扩展性。

gRPC对浏览器的支持度较低，使其适合内部API（非公开）和移动开发。移动应用通常不需要浏览器，而gRPC的小消息尺寸可以保持移动设备的处理速度。

物联网API需要双向流，因为许多设备可能同时向API服务器发送消息。gRPC可以同时处理和响应来自多个客户端的多个请求。而REST只支持单向通信。由于带宽受限，物联网API还需要轻量级消息传递。最后，使用gRPC连接物联网设备（例如手机到后端API）更为简便。

微服务最佳选择：尚无定论

REST和gRPC都用于微服务。虽然REST在微服务中应用更广泛，但gRPC的特性特别适合这一领域。

微服务架构可以利用gRPC的内置代码生成功能，使得用不同编程语言编写的微服务能够相互通信。gRPC的有效载荷大小和双向流也允许微服务之间进行更快、更高效的通信。

了解更多：如何编写开发文档

如何记录REST和gRPC API

REST和gRPC需要提供API组件和流程全面手册的参考文档。对于REST来说，这意味着对所有资源、端点、参数等的描述。参考文档通常由第三方工具生成，该工具依赖于API符合预定义结构（如OpenAPI）。两种API也都需要API概念文档，用于提供入门指南、用例和教程。与参考文档不同，概念文档是由人工编写的。

接下来，我们将讨论每种API的一些具体注意事项。

REST APIs

OpenAPI 是一种 RESTful API 规范，用于描述符合 RESTful 架构的 API。规范提供了一个接口，让人类和计算机都能理解 API 以及如何与之交互。符合 OpenAPI 规范的 API 可以利用大量可用的文档工具，例如 Baklib、Swagger、Stoplight 或 Readme.io。其他类型的 API 也有可能采用 Open API 规范。

同时，请查看我们关于 SwaggerHub 替代方案的文章。

gRPC APIs

gRPC 的可寻址实体（作为过程）与 Open API 的资源（数据对象）相反。因此，gRPC API 并不是应用 Open API 标准的最佳候选者。与 REST API 相比，可用于 gRPC 的文档工具数量要少得多。

然而，有些 API 是用 gRPC 实现的，但使用 Open API 标准作为其规范语言。这样做颠倒了 gRPC 的过程实体，并将客户端交互重点放在资源数据对象上。

gRPC 可以通过像 REST API 那样的 HTTP URL 暴露实体，而不是访问过程。通过使用 OpenAPI，gRPC API 可以利用与 REST 相同的强大工具进行文档编制。

改造现有的 gRPC API 以符合 Open API 规范不太可能，因为这很困难。这就是为什么更有可能从一开始就开发一个新的 gRPC API，并将 Open API 纳入考虑。有些工具允许您使用协议缓冲区创建组合的 REST/gRPC API，并生成 Open API 规范。一般过程包括使用 OpenAPI 选项注释 gRPC 服务，并将这些服务映射到服务器定义中的 REST API 调用。然后，您可以像 REST API 一样从命令行生成并提供 Swagger 文档。

另请阅读：REST 与 SOAP：有何不同？

总结

REST 和 gRPC 是两种 API 架构风格，它们都为构建 API 提供了一套规则。选择使用哪种架构风格取决于您希望构建的应用程序类型。REST 的特性使其非常适合需要浏览器支持的面向公众的 API，而 gRPC 的小型负载和双向流非常适合移动开发和物联网。两者对于微服务架构都是可行的选择，但 REST 在这一领域仍然占据主导地位。