在开发应用程序接口（API）时，你可能会经常遇到 REST 和 gRPC 这两种技术。尽管 REST 长期以来在这一领域占据主导地位，但 gRPC 作为一种强大的竞争对手，其价值日益凸显。
REST 和 gRPC 是两种不同的 API 设计方法。API 充当服务之间的通信桥梁，这些服务可能代表着部署在不同计算机上或使用不同编程语言编写的复杂系统。
本文将深入探讨 REST 和 gRPC，分析它们的异同之处，并探讨各自的适用场景。
什么是 REST？
REST（表述性状态转移）是一种架构风格，它定义了软件组件之间如何交换数据的规则。REST 的基础是网络标准通信协议 HTTP。
所有基于 REST 架构风格设计的 API 都被称为 RESTful API。另一方面，遵循 REST 架构设计的 Web 服务则被称为 RESTful Web 服务。
REST 架构风格遵循以下原则：
- 统一接口：服务器端应以标准化的格式传输数据。然而，传输的数据格式可以与服务器应用程序内部资源的表示形式有所不同。
- 无状态：服务器应该独立处理每个客户端请求，不受先前请求的影响。客户端对资源的请求可以按任何顺序进行，并且每个请求都是相互隔离的。
- 分层系统：在服务器和客户端之间可以存在一层授权中介。客户端可以连接到这些授权中介，并仍然接收来自服务器的响应。
- 可缓存性：一些响应可以存储在中介或客户端上，以缩短响应时间。
- 按需编码：服务器可以通过将软件代码传输到客户端，来临时定制或扩展客户端功能。
REST 的优势
- 可扩展性：REST API 因其可扩展性而著称，因为它们优化了客户端-服务器的交互。缓存和无状态是减少服务器负载的主要特性。
- 灵活性：RESTful API 提供了完全的客户端-服务器分离。这种服务将解耦并简化各种可以独立发展的服务器组件。
- 独立性：您可以使用不同的编程语言编写服务器和客户端应用程序，而不会影响 API 的设计。
REST 的应用场景
- 网络 API
- Web 服务
- 微服务架构
什么是 gRPC？
gRPC（远程过程调用）是一个可以在任何环境中运行的远程过程调用（RPC）框架。这个开源框架被设计成高性能协议，可以高效地连接数据中心之间和数据中心内部的服务。
客户端应用程序可以调用另一台计算机上的服务器应用程序中的方法，就像它是本地对象一样。使用 gRPC，你可以定义服务，并指定可以远程调用的方法及其参数和返回类型。
gRPC 具有可插入的健康检查、身份验证、负载均衡和跟踪支持。该框架使用 HTTP/2 和 Protocol Buffers 进行数据传输。在数据交换时，会调用过程而不是资源 URL。
gRPC 的优势
- 可扩展性：gRPC 允许你使用单个命令安装运行时环境，并开始扩展到每秒数百万个 RPC。
- 简单的服务定义：使用 Protocol Buffers 来定义你的服务并使它们运行。
- 跨平台：该框架为不同平台和语言生成惯用的客户端和服务器存根。
- 双向流和集成身份验证。
gRPC 的应用场景
- 网络 API
- Web 服务
- 流媒体应用
- 微服务通信
REST 和 gRPC 的相似之处
- 数据交换机制：两种架构设计都允许服务器和客户端交换数据。然而，这些数据是按照特定的规则共享的。
- 适用于可扩展的分布式系统：REST 和 gRPC 的异步通信和无状态设计使得它们的 API 易于扩展。
- 基于 HTTP 的通信：两者都使用 HTTP，这是网络上最流行的通信协议。
- 灵活性：你可以将 REST 和 gRPC 与不同的编程语言和技术结合使用。
REST 与 gRPC：深入比较
REST 和 gRPC 服务在以下方面有所不同：
数据交换
在 REST API 中，从一个软件组件传递到另一个软件组件的数据必须以 JSON 格式表示。JSON 必须被序列化并转换为用于数据交换的编程语言。然而，REST API 还可以交换 HTML 和 XML 等数据格式。
默认情况下，gRPC 使用 Protocol Buffers 格式。但它也支持 JSON。Protocol Buffers 不是人类可读的。服务器使用 Protocol Buffer 接口描述语言来定义数据结构。然后 gRPC 将数据结构序列化为二进制格式。之后，它将数据反序列化为任何指定的编程语言。
通信模式
在 REST 中，客户端向服务器发送单个请求，然后服务器发送回复作为响应。客户端必须等待服务器的响应才能继续操作。这是一个请求-响应模型。
在 gRPC 中，客户端可以发送单个或多个服务器请求，从而产生单个或多个回复。数据连接可以是多对多、多对一、一对多或一对一。gRPC 使用客户端响应通信模型。
代码生成
gRPC 具有内置的本机服务器端和客户端代码生成功能。你可以通过 Protocol Buffers 编译器以不同的语言找到这些功能。gRPC 在 proto 文件中定义结构后，会生成服务器端和客户端代码。
REST 缺乏内置的代码生成功能。如果你需要此功能，可以使用第三方工具。
HTTP 协议
REST API 使用 HTTP/1.1。要在 REST 服务上发送请求，你需要资源 URL。HTTP/1 在计算机和 Web 服务器之间发送信息。REST 服务中的资源 URL 对客户端可见。API 设计者控制资源 URL 的结构。
gRPC 使用 HTTP/2。这个 HTTP 版本于 2015 年推出，用于 Internet Explorer、Safari 和 Chrome 等浏览器。与将所有内容都保留为纯文本的 HTTP/1 不同，这种较新的格式利用二进制格式封装，从而提供更多的数据传输选项并加快整个过程。
负载数据结构
REST 使用 XML 或 JSON 来发送和接收数据。JSON 是 REST 中发送动态数据最常用的格式，因为它灵活且不需要任何结构。JSON 数据也是人类可读的。JSON 唯一的问题是速度不够快，因为它必须在数据传输过程中进行序列化和转换。
gRPC 使用 Protocol Buffers 来序列化有效负载数据。这是一种高度压缩的格式，可以减少消息的数据大小。该框架使用 Protobuf 自动将强类型消息转换为客户端和服务器的编程语言。
浏览器支持
所有浏览器都支持 REST，因为它使用 HTTP/1.1。这使得它成为 Web 服务和 API 的理想选择。
gRPC 对浏览器的支持有限，因为它基于 HTTP/2。要支持所有浏览器，你必须添加 gRPC-web 作为代理层。因此，内部系统大多采用 gRPC。
客户端-服务器耦合
REST 是一种松散耦合的架构设计。这意味着客户端和服务器不需要了解彼此的实现细节。随着时间的推移，此功能可以更轻松地发展 RESTful API，因为你在更改服务器定义时无需更改客户端代码。
gRPC 是一个紧密耦合的框架，其中服务器和客户端必须能够访问相同的原型文件。如果需要对文件进行任何更改，还必须更新服务器和客户端。
REST 与 gRPC 对比
| 功能 | REST | gRPC |
| HTTP 协议 | HTTP/1.1 | HTTP/2 |
| 浏览器支持 | 使用 HTTP/1.1 时支持所有浏览器 | 使用 HTTP/2 时浏览器支持较少 |
| 代码生成 | 使用第三方工具 | 内置代码生成功能 |
| 设计方法 | 面向实体的设计 | 面向服务的方法 |
| 数据访问 | 资源 URL | 服务调用 |
| 双向数据流 | 不可用 | 可用 |
| 实现 | 无需通用软件即可实现客户端或服务器端的 REST | 客户端和服务器端都需要 gRPC 软件 |
| 通信模型 | 单个客户端与单个服务器通信 | 多种通信模型，例如一个客户端向多个服务器发送请求、一台服务器与多个客户端通信或一台服务器与一个客户端通信。 |
何时使用 REST
RESTful API 和 Web 服务非常流行。RESTful 服务易于实现、结构化数据、灵活且可读。你可以在以下情况下使用 REST：
- 基于 Web 的架构：你可以使用 REST 架构设计创建 Web、移动和多平台 API。
- 简单的数据通信：REST 使用 JSON，一种易于读取的数据格式。
- 面向公众的 API：如果你想让公众访问数据并使用你的 API，REST 将是一个不错的选择，因为它具有可读性。
何时使用 gRPC
gRPC 不像 RESTful 服务那样流行。然而，它也有独特的功能，使其在以下应用中脱颖而出：
- 多语言系统：gRPC 适合使用不同编程语言编写且 API 不太可能改变的微服务架构。
- 微服务连接：双向流和较低的浏览器支持等功能使 gRPC 成为内部 API 的不错选择。
- 实时流网络：你可以将 gRPC 与处理大量数据负载并需要实时流的内部服务结合使用。
作者观点
尽管 gRPC 的一些特定功能可能会在物联网等应用程序中超越 REST，但后者因其可读性、灵活性和广泛采用而胜出。gRPC 较低的浏览器支持使得它对于想要构建 Web 服务的开发人员来说不是一个好的选择。
对 RESTful 服务的普遍支持使 REST 成为 Web 和微服务集成的理想 API 架构风格。
结论
REST 和 gRPC 是你在构建下一个 API 时可以选择的众多 API 架构风格之一。最终的选择将取决于你想要构建的产品。RESTful 服务非常适合构建面向公众的 API，而 gRPC 则适合不需要浏览器支持的移动应用程序等服务。
接下来，请查看我们关于如何使用 Java 从头开始创建 gRPC 的文章。