gRPC 与 REST

在庞大的互联网地图中，应用程序编程接口 (API) 是连接城市、乡镇、海滩和其他目的地的道路。API 支持软件应用程序相互通信，以交换数据、特性和功能。Imperva 2023 年的一份报告发现，约 71% 的互联网流量由 API 调用组成，这表明这项技术对于现代应用程序和企业的运作至关重要。

毫无疑问，了解如何构建 API 是大多数开发人员的一项基本技能。但是，作为如此重要的基础设施，其种类也多种多样。

延续上文的比喻：12 车道高速公路并不比单车道地面道路更“优越”，前者会破坏城市社区构造，而后者在拥堵区域会引发灾难。构建 API 的不同架构风格（如 REST 和 gRPC）也是如此：它们各有优劣，而了解这些优缺点对于建立健康的基础设施至关重要。

表述性状态转移 (REST) 是一组设计原则（或架构限制）：统一接口、客户端-服务器解耦、无状态、可缓存性、分层系统架构和按需代码（可选）。使用这些原则构建的 API 称为 REST API 或 RESTful API。

REST API 可以使用多种编程语言和数据格式，但前提是符合 REST 原则。这是构建 API 最常见的方式。

REST API 使用 GET、POST、PUT 和 DELETE 等 HTTP 请求（又称“HTTP 方法”）来执行标准数据库函数。这些操作可用于创建、读取、更新和删除资源记录，通常称为“CRUD”。服务器端资源由称为“端点”的 URL 标识。

例如，REST API 会使用 GET 请求来检索记录。POST 请求用于创建新记录。PUT 请求用于更新记录，DELETE 请求用于删除记录。所有 HTTP 方法都可以在 API 调用中使用。精心设计的 REST API 类似于在具有内置 HTTP 功能的 Web 浏览器中运行的网站。

资源信息可以通过多种消息格式传递到客户端，包括 JavaScript Object Notation (JSON)、HTML、XLT、Python、PHP 或纯文本。JSON 很受欢迎，因为它既能被人类和机器读取，而且与编程语言无关。

了解更多关于 REST 与 GraphQL 的信息

浏览器支持：由于 REST API 使用 HTTP/1.1 和标准 HTTP 方法，以及 XML 和 JSON 等格式，因此可兼容浏览器。

易于使用：由于其简单性和普及性，REST 被广泛认为更容易理解，尤其是对初学者而言。GitHub 和其他地方提供的工具、教程和指南非常丰富。

灵活性：REST API 通常在客户端和服务器之间具有松散耦合性。这一灵活性可以更轻松、更快捷地进行更改：只需更改任意一端，而无需同时更改另一端。

强大的生态系统：REST API 拥有大量工具以及广泛的支持和文档。例如，OpenAPI 规范 (OAS) 可提供 REST API 参数和功能的行业标准定义。最新版本的 OAS (OAS 3.1) 完全兼容 JSON Schema，且可提供使用 SPDX 标识符的标准化标识等功能。

对 HTTP/1.1 的依赖：虽然 REST 对 HTTP/1.1 的使用为其提供了通用浏览器支持和标头中的一些自定义功能，但它也使 REST API 无法享受较新 HTTP/2 的一些优点。那些缺失的优点包括：双向流式传输；REST 仅支持一元流式传输，即一个请求跟随一个响应。

速度较慢且效率较低：与 HTTP/1.1 一样，REST 对 XML 和 JSON 等格式的依赖既有优点也有缺点。这些格式人类可读，这一点很好，但它们也是相对较大的文件，这意味着传输速度较慢。

需要额外的工具：REST 的生态系统或许很强大，但它之所以如此强大，是因为部分功能尚未内置于架构中。例如，代码生成可通过 REST 插件的形式实现，但这仍然属于额外的步骤，并且更加复杂。

gRPC 是 Google 最初开发的一个开源框架，可作为远程过程调用 (RPC) 的特定实现。它目前由云原生计算基金会 (CNCF) 管理。

gRPC 的名称含义颇具戏谑意味——开发人员调侃称其既可代表“Google 远程过程调用”，也可视作“gRPC 远程过程调用”或其他变体。无论如何，gRPC 与其他 RPC 类似，均可确保远程调用在外观和功能上呈现本地调用形式。

RPC 作为客户端/服务器交互模型，常用于 API 开发。在 RPC 模型中，客户端通常与“存根”中介进行交互。此存根可转换数据以便传输，一旦从服务器接收到所请求的结果，它就会将其转换回客户端的原始格式。RPC 框架多种多样，包括 XML-RPC 和 JSON-RPC。

此类轻量级 RPC 框架易于使用，且具备简化开发和网络通信抽象等优势。然而，微服务架构和高数据负载系统等环境通常需要更高的性能框架，而 gRPC 的开发正是为了满足这一需求。

gRPC 采用称为“协议缓冲区 (Protobuf)”的接口定义语言 (IDL)，将结构化数据序列化为二进制文件。由于二进制文件相较 JSON 或 XML 更为紧凑，因此能以更快的速度传输更大的有效载荷。

gRPC 还使用 HTTP/2 来支持双向流式传输，因此成为了分布式环境（尤其是需要实时通信的环境）中 API、微服务架构、流式传输应用程序和物联网 (IoT) 设备连接的理想选择。

速度：gRPC 可通过 Protobuf 将来自不同语言（包括 Java、Python、Ruby 等）的数据序列化和反序列化为二进制有效负载以便传输。该代码为轻量级，因此使用 gRPC API 可以减少数据交换中的传输时间和延迟。

代码生成：gRPC 包含名为 [protoc] 的 Protobuf 编译器，且具备原生代码生成功能。在 .proto 文件中定义数据结构后，gRPC 即可生成客户端和服务器端代码。

HTTP/2 支持：依靠 HTTP/2 传输协议，gRPC 支持各种类型的流式传输。例如，除了客户端和服务器端流式传输之外，它还支持双向流式传输，即客户端和服务器可以在读/写流中独立发送消息。

拦截器：gRPC 支持被称为拦截器的中间件，可实现更多功能。可以安装拦截器来实现安全性、身份验证、指标分析等。

取消和超时：gRPC 支持取消（又称“超时或截止时间”），即在指定时间结束后取消调用。

新颖性和生态系统：虽然 gRPC 确实包括代码生成等额外功能，但它是一个相对较新的架构，在 2016 年才首次发布。与较旧的架构风格相比，这种新颖性使文档和支持受到限制。

陡峭的学习曲线：部分开发人员发现，gRPC 的学习曲线相比 REST 更为陡峭。其二进制数据序列化可实现高效通信，但不具备人类可读性。

缺乏浏览器支持：由于 Web 浏览器本身并不支持 gRPC 协议，因此无法从基于浏览器的应用程序直接调用 gRPC 服务。解决这一问题的方法之一是采用代理，如 gRPC-Web。gRPC-Web 本质上可充当浏览器 HTTP 和 gRPC 协议之间的转换层。

REST 和 gRPC 有许多共同的元素，并且都用于构建可扩展系统。相似之处包括：

客户端/服务器架构：gRPC 和 REST 均为客户端/服务器架构，且采用请求-响应格式支持客户端和服务器进行通信和数据交换。在此架构中，客户端会发送请求，服务器则通过返回请求数据或执行所请求的操作来响应。

平台独立性：gRPC 和 REST 支持基于不同平台和操作系统而构建的服务进行通信。

无状态：REST 和 gRPC 都被视为无状态，这意味着每个请求都包含完成它所需的所有信息。服务器不需要存储有关先前请求的任何信息。

语言支持：这两种架构风格均与语言无关，这意味着此类 API 可用于以各种编程语言编写的应用程序。这一特性赋予了二者跨编程环境的可移植性。

使用 HTTP：REST 和 gRPC 都依赖于基于 HTTP 的通信。但是，gRPC 使用 HTTP/2，而 REST 依赖于 HTTP/1.1。此外，gRPC 抽象化底层 HTTP/2 通信协议，而 REST 中 HTTP 通信的抽象程度较低。

REST 和 gRPC 之间的主要区别可以帮助开发人员确定哪种最适合他们正在构建的 API。这些区别包括：

数据格式：REST API 主要使用基于文本的格式，例如 JSON 和 XML。gRPC 则使用 Protobuf 将数据编码为二进制格式。

通信模式：REST 仅支持一元通信，即一个请求后接一个响应。gRPC 则支持其他模式，包括双向流式传输（客户端和服务器独立进行交换）、服务器流式传输（单个请求触发多个响应）和客户端流式传输（多个请求生成单个响应）。

设计模式：gRPC 具有面向服务的设计，其中可调用的服务器运营被定义为服务或功能。在 REST 中，设计以资源为导向，其中使用 HTTP 方法通过 URL 定义的端点访问服务器资源。

耦合：gRPC 的客户端和服务器紧密耦合，这意味着客户端和服务器都必须访问同一个中间件 proto 文件。其中一个发生改变，另一个也随之改变。REST 是松散耦合的。这种独立性意味着一个组件的更改不会影响其他组件。

代码生成：gRPC 具备内置代码生成功能；REST 则不具备此功能，但有插件可供选择。

实施：REST 无需特定软件，且可支持浏览器。gRPC 则需要在服务器端和客户端安装特定的软件。

REST 是备受欢迎的 API 设计选择，其原因在于简易性、广泛兼容性与多用途特性——这些特性使其成为了众多应用程序的优选方案。对于公开式 API，REST 通常是更明智的选择，因为它的用途更广泛，且更易于理解。许多开发人员更熟悉 REST，并且已部署 REST 专用的关键基础设施，包括服务器、API 管理工具、开发工具和各种测试工具。

REST 还支持内置缓存（即存储频繁访问的数据），无论是本地存储还是代理存储。缓存可以显著提高速度和效率，尽管它还需要集成各种验证、身份验证和过期信息。

REST 同样因其 HTTP/1.1 支持和通用浏览器兼容能力，成为了 Web 服务和 Web API 的首选。对于更简单的数据通信，它通常比 gRPC 更为合适。凭借松散耦合和更低的复杂性，它能够提高系统架构的可扩展性，同时支持环境随着时间的推移灵活演进。然而，这种适应性需以性能为代价来实现。

gRPC 是一个相对较新的架构，越来越多的开发人员青睐它的速度、效率和内置工具。它通常用于实时流式应用程序和需要高性能以及分布式系统中高数据负载处理的复杂 API。虽然比 REST 更复杂，但 HTTP/2 和 Protobuf 的使用为 gRPC 提供了更大的性能可扩展性。

gRPC 非常适合微服务架构，因其能够实时流式传输双向数据，并允许应用程序中的不同服务独立执行并行发送和接收操作。由于其快速紧凑的数据传输特性，且移动应用程序通常较少依赖浏览器，gRPC 在移动应用领域也备受青睐。

gRPC 也适用于连接 IoT 项目到后端 API，并凭借其紧凑的有效载荷、低延迟和高性能效率与低功耗技术无缝兼容。