API 之争—gRPC VS REST

发布日期: 2024-01-11

更新日期: 2024-02-26

文章字数: 2.4k

阅读时长: 8 分

阅读次数:

在构建新的基于web 的服务时，首先出现的问题之一是，“我将如何与其交谈？”有很多选择需要考虑。这里我们将重点讨论 REST 和gRPC。REST 是一个架构/设计概念，而 gRPC 更多的是一个框架。然而，两者都是用于在 Web 服务之间进行通信的流行工具。

多年来，REST API 一直是 Web 编程中用于通信目的的核心服务。然而，gRPC 最近开始蚕食其核心地位。这篇文章将对两者进行比较，看看它们如何比较、它们的共同点和不同点。

简介

REST—（REpresentational State Transfer）这个术语是 Roy Fielding 在2000年的一篇博士论文中首次引入的，他在论文中解释说，REST原则以前被称为“HTTP对象模型”，并用于设计HTTP 1.1和统一资源标识符(Uniform Resource Identifiers, URI)标准。REST在web开发人员中变得非常流行。许多应用程序依赖REST实现内部序列化和通信模式。为了使 API 成为 RESTful，必须遵循一组约束。这些将使 API 更易于使用且更易于发现。

gRPC—（gRPC Remote Procedure Calls）远程过程调用最初是由Google创建的。它源于谷歌内部单一的通用RPC基础设施Stubby，该基础设施连接了谷歌数据中心内部和数据中心之间运行的所有微服务。Stubby经过重新设计，扩展了其对移动、物联网和云的适用性，并创建了一个标准化的开源基础设施。

工具类型

REST（表述性状态转移）是一种关注资源的架构模式或设计概念。软件解决方案被构建为资源集合，供用户通过使用一致的界面进行访问和交互。

在REST中，任何可以命名的信息都是资源。这可以是一个非虚拟对象、一个图像、一个文档、一组其他资源，等等。最初，web资源被定义为通过其url标识的文档或文件，然而，它们现在有了更通用和抽象的定义。

REST 使用资源标识符来确定组件之间交互所涉及的特定资源。-

gRPC是一个开源的RPC框架，可以在任何环境中运行。 https://grpc.io/表示该名称代表远程过程调用。 gRPC 背后的目标之一是让您感觉就像在同一台计算机上使用服务一样。因此，需要建立两方：服务器和客户端。 “.proto”格式的API合约提供了双方之间通信的共享接口。这意味着客户端不需要搜索 API 文档，因为它已经在本地级别指定。除了使用 .proto 就数据结构达成一致之外，gRPC 合约还能够定义类型并防止在类型不匹配时将客户端请求一起发送。

规范、实现和范式

所有 API 都遵循一种范式，无论是“RPC”、“REST”还是“query language”。它们涉及构建API的一般方法，而不是特定的工具或规范。它们是一个概念，而不是有形的东西。

REST 是一种范式，尚未转变为规范。没有正式实施；然而，构建 REST API 通常只涉及选择适当的标准和工具。

同时，gRPC 是一种遵循 RPC 范式的实现。尽管谷歌记录了该协议，但它没有标准或规范。

有效负载格式

有效负载的格式是 REST 和 gPRC 之间的主要区别之一。在 REST 中，消息通常包含 JSON。这并不是绝对必需的，因为理论上任何内容都可以作为响应发送，然而，在实践中，整个 REST 生态系统（工具、最佳实践、教程）都是基于 JSON 的。

相比之下，gRPC 接受并返回 Protocol Buffers（或 Protobuf）消息，该消息使用二进制数据来序列化结构化数据。从性能的角度来看，Protobuf 是一种高效的打包格式，而 JSON 是一种文本格式。 JSON可以被压缩；然而，这将导致失去文本格式的好处。 REST 确实提供跨语言支持，因为所有请求都是通过数据交换格式（例如 JSON 或 XML）处理的。

gRPC 的语言支持依赖于 proto3（Protocol Buffer 的最新版本）的语言采用，它支持 Java、C#、C++、Python、Ruby、JavaScript 和 Objective-C。与通过 REST 传输的 JSON 或 XML 数据相比，protobuf 中传输数据的序列化可显着提高性能。

传输协议

REST 和 gPRC 也使用不同的传输协议。 REST 依赖于 HTTP（最典型的是 HTTP 1.1）和通信的请求-响应模型。与此同时，gRPC 依赖于较新的 HTTP/2 协议，该协议允许双向通信。

HTTP/2 对 HTTP 1 所做的改进是多方面的，包括：

HTTP 1.1 庞大且复杂
HTTP 1.1 中的页面加载时间较慢
HTTP 1.1 对延迟更加敏感，因为每个单独的请求都需要 TCP 握手
在 HTTP 1.1 中发送多个请求变得更加困难

最显着的改进是 HTTP/2 使用多路复用流 - 一个 HTTP/2 TCP 连接可以支持多个双向流，这些双向流可以交错，这意味着无需排队，并且可以同时发送多个请求，而无需建立新的 TCP 连接每一个。服务器现在还可以通过已建立的连接向客户端推送通知。

易用性vs复杂性

REST 紧密构建在 HTTP 之上并包含其功能，这使得完全实现 REST 变得困难。它仍然非常受欢迎和成功，但这部分是因为大多数实现没有完全遵循其理念，并且仅使用其部分原则。

尽管如此，REST 在构建方面优先考虑简单性。它是轻量级的并且具有简单的 URL，例如如果您向“…example.com/users/10”发送 DELETE 请求，它将删除该数据；如果您向同一 URL 发送 GET 请求，它将返回与 ID 10 的用户相关的数据。REST 重点关注服务之间通信的内容，而不是通信的方式。 HTTP 动词（例如 GET、DELETE、POST 等）用于请求，HTTP 状态代码用于描述请求状态。但是，您必须指定标头、方法、正文等。

相比之下，gPRC 通过 grpc-web-client 抽象了指定标头、方法、正文等的需要。此外，gRPC 具有明确定义的状态代码，可以准确识别发生了什么问题。 gRPC 还提供具有清晰接口和高效请求和响应消息的服务。它直接借用了编程语言的概念，例如接口、函数和数据结构。 gRPC 能够自动生成客户端库。

流与请求-响应

REST 仅支持 HTTP 1.1 中提供的请求-响应模型。然而，gRPC 利用了 HTTP/2 的全部功能，从而允许持续的信息流。 gRPC 支持多种类型的流式处理：

服务端流式传输：收到客户端请求消息后，服务器发回响应流。在发送回所有响应之后，服务器的状态详细信息和可选的尾随元数据将发送回服务器端以完成。一旦获得服务器的所有响应，客户端就完成了。
客户端流式传输：客户端向服务器发送多个请求的流。除了其状态详细信息和可选的跟踪元数据之外，服务器通常(但不一定是在接收到所有客户请求之后)使用单个响应进行响应。
双向流：客户端和服务器以自由形式向彼此发送信息（客户端发起序列除外）。最终，客户端关闭连接。