gRPC vs REST：创建 API 的方法比较

本文对 gRPC 和 REST 的特征和区别进行了介绍，这可能是当今创建 API 最常用的两种方法。

以下将从这两种工具的特征开始，也就是它们是什么以及提供什么功能。然后，将根据七个方面对它们进行比较，这对现代系统来说是最重要的 7 个类别。

其类别如下：

1. 底层 HTTP 协议

2. 支持的数据格式

3. 数据大小

4. 吞吐量

5. 定义

6. 易于采用

7. 工具支持

一、gRPC 的介绍

当人们听到 API 时，可能马上想到 REST API。然而，REST 是构建 API 的众多方法之一。它并不是适用于所有用例的灵丹妙药。还有其他方法，远程过程调用 (RPC)只是其中之一，而 gRPC 可能是使用 RPC 最成功的框架。

尽管 gRPC 是一种相当成熟和高效的技术，但它仍然被视为一种新技术。因此，尽管在某些用例中非常方便，但它没有 REST 被广泛采用。

本文主要介绍 gRPC，并指出它可以发挥作用的用例。

二、什么是 REST？

表述性状态转移（REST）可能是创建公开任何类型 API 的应用程序的最常用方法。它使用 HTTP 作为底层通信媒介。正因为如此，它可以从 HTTP 的所有优点中获益，例如缓存。

• 客户端-服务器通信

• 无状态通信

• 缓存

• 统一接口

• 分层系统

• 按需编码

REST 的两个关键概念是：

（1）端点：表示特定资源的唯一统一资源定位符(URL)；可以看作是通过互联网访问特定操作或数据元素的一种方式。

（2）资源：在特定 URL 下可用的特定数据块。

此外，还有一个叫做 Richardson 成熟模型的描述——这是一个描述 REST API 中“专业性”程度的模型。它根据特定 API 具有的特征集将 REST API 划分为 3 个级别(或 4 个级别，取决于是否将级别 0 计算在内)。

其中一个特征是 REST 端点应该在 URL 中使用名词，并使用正确的 HTTP 请求方法来管理其资源。

• 示例：用 DELETE user/1 代替 GET user/deleteById/1

至于 HTTP 方法及其相关操作，如下所示：

• GET—检索特定的资源或资源集合。

• POST—创建一个新的资源。

• PUT—修改整个资源。

• PATCH -特定资源的部分更新。

• DELETE—删除指定 id 的资源。

成熟度模型规定的远不止这些。例如称为 HyperMedi 的概念。HyperMedia 将数据的呈现和对客户端可以执行的操作的控制结合在一起。

对成熟度模型的完整描述超出了本文的范围。

三、什么是 gRPC?

gRPC 是远程过程调用（RPC）这个相对古老的概念的另一种实现。谷歌的开发人员创建了它，这就是为什么它的名称里有“g”的原因。它可能是处理 RPC 最现代和最有效的工具，也是 CNCF 孵化项目。

gRRC 使用谷歌公司的协议缓冲区作为序列化格式，同时利用 HTTP/2 作为传输介质数据，尽管 gRPC 也可以使用 JSON 作为数据层。

• 方法：gRPC 的基本构建块，每个方法都是一个远程过程调用，它接受一些输入并返回输出。它执行用所选编程语言进一步实现的单个操作。目前，gRPC 支持 4 种方法：

① Unary：经典的请求-响应模型，该方法接受输入并返回输出。

② 服务器流：该方法接受消息作为输入，同时返回消息流作为输出。gRPC 保证了单个 RPC 调用中的消息排序。

③ 客户端流：该方法将消息流作为输入，处理它们直到没有消息为止，然后返回一条消息作为输出。与上面类似，gRPC 保证在单个 RPC 调用中进行消息排序。

④ 双向流：该方法将消息流作为输入，并将消息流作为输出返回，有效地使用了读和写两个消息流。两个流都独立运行，并且将消息顺序保留在流级别上。

• 服务：表示一组方法，每个方法在服务中必须有其唯一的名称。服务还描述了安全性、超时或重试等特性。

• 消息：表示方法的输入或输出的对象。

gRPC API 定义以.proto 文件的形式编写，其中包含上述所有三个基本构建块。此外，gRPC 提供了一个协议缓冲区编译器，它从.proto 文件生成客户端和服务代码。

用户可以随心所欲地实现服务器端方法，必须坚持使用 API 的输入输出契约。

在客户端，有一个叫做客户端(或 stub)的对象——类似于 HTTP 客户端。它知道来自服务器的所有方法，只处理调用远程过程并返回它们的响应。

四、gRPC 和 REST 的比较

（1）底层 HTTP 协议

这是第一类，可能也是最重要的一类，因为它的影响也可以在其他方面看到。

一般来说，REST 是基于请求-响应的，并使用 HTTP/1.1 作为传输媒介。这里必须使用不同的协议，例如 WebSocket 或任何类型的流或更持久的连接。

还可以实现一些简单的代码，使 REST 看起来像消息流。更重要的是，使用 HTTP/1.1 REST 需要每个请求-响应交换一个连接。对于长时间运行的请求，或者当网络容量有限时，这种方法可能会有问题。

当然，可以使用 HTTP/2 来构建类似 REST 的 API；然而，并不是所有的服务器和库都支持 HTTP/2。因此，其他地方可能会出现问题。

另一方面，gRPC 只使用 HTTP/2。它允许通过单个 TCP 连接发送多个请求-响应对。这种方法可以显著地提高应用程序的性能。

• 结果：gRPC 略有获胜

（2）支持的数据格式

假设 REST API 使用 HTTP/1.1 的默认情况，那么它可以支持多种格式。

REST 通常不对消息格式和样式施加任何限制。基本上，任何一种可以序列化为普通旧文本的格式都是有效的。用户可以在特定场景中使用最适合自己的任何格式。

在 REST 应用程序中发送数据的最流行格式无疑是 JSON。XML 排在第二位，因为有大量的较旧/遗留应用程序。

然而，当使用 REST 和 HTTP/2 时，只支持二进制交换格式。在这种情况下，可以使用 Protobuf 或 Avro。当然，这种方法也有它的缺点，但在以下几点中会详细说明这一点。

同时，gRPC 只支持两种数据交换格式：

①Protobuf —默认情况下。

②JSON—当需要与原有 API 集成时。

如果用户尝试使用 JSON，那么 gRPC 将使用 JSON 作为消息的编码格式，而使用 GSON 作为消息格式。此外，使用 JSON 需要做更多的配置。

• 结果：REST 获胜，因为它支持更多格式。

（3）数据大小

默认情况下，gRPC 使用二进制数据交换格式，这显著地减少了通过网络发送的消息的大小：研究表明，以字节计算，大约减少了 40%～50%，而从以前的一个项目中获得的经验表明，甚至减少了 50%～70%。

以上提供了 JSON 和 Protobuff 之间相对深入的大小比较。本文作者还提供了一个生成 JSON 和二进制文件的工具。这样就可以重新运行他的实验并比较结果。

本文中的对象相当简单。不过，一般的规则是——嵌入的对象越多，JSON 的结构越复杂，它就会比 Protobuf 更重。50%的大小差异有利于 Protobuf 是一个很好的基线。

在使用 REST 的二进制交换格式时，可以最大限度地减少或消除这种差异。然而，这不是最常见的，也不是最受支持的 RESTful API 方式，因此可能会出现其他问题。

• 结果：默认情况下，gRPC 获胜；在两者都使用二进制数据格式的情况下，双方为平局。

（4）吞吐量

同样，在 REST 的情况下，一切都取决于底层 HTTP 协议和服务器。

在默认情况下，基于 HTTP/1.1 的 REST，即使是最高性能的服务器也无法击败 gRPC 的性能，特别是当使用 JSON 时添加序列化和反序列化开销时。虽然当切换到 HTTP/2 时，差异似乎有所减少。

至于最大吞吐量，在这两种情况下，HTTP 都是一种传输媒介，因此它具有无限扩展的潜力。因此，一切都取决于正在使用的工具以及对应用程序的精确操作，因为设计没有限制。

• 结果：默认情况下为 gRPC；在同时使用二进制数据和 HTTP/2 的情况下，gRPC 略胜一筹。

（5）定义

在这一部分中，将描述如何在这两种方法中定义消息和服务。

在大多数 REST 应用程序中，只是将请求和响应声明为类、对象或特定语言支持的任何结构。然后，依靠提供的库来序列化和反序列化 JSON/XML/YAML 或任何需要的格式。

此外，目前正在努力创建能够根据 Swagger 的 REST API 定义用所选编程语言生成代码的工具。然而，它们似乎是在 alpha 版本中，所以仍然可能会出现一些错误和小问题，这将使它们难以使用。

REST 应用程序的二进制格式和非二进制格式之间几乎没有区别，因为这两种情况下的规则大致相同。对于二进制格式，只是以特定格式所需的方式定义所有内容。

此外，可以通过来自底层库或框架的方法或注释来定义 REST 服务。该工具还负责将其与其他配置一起向外部世界公开。

在 gRPC 的情况下，将 Protobuf 作为默认的并且事实上是编写定义的唯一方式。必须在.proto 文件中声明所有内容：消息、服务和方法，所以事情非常简单。

然后使用 gRPC 提供的工具生成代码，只需要实现自己的方法。在那之后，一切都应该按预期工作。

此外，Protobuf 支持导入，因此能够以一种相当简单的方式将设置扩展到多个文件。

• 结果：在这里没有赢家，给出的描述和建议是，选择最适合自己的方法。

（6）易于采用

在这一部分中，将比较现代编程语言中对每种方法的库/框架支持。

本文作者表示，在他作为软件工程师的职业生涯中，遇到的每种编程语言(Java、Scala、Python)都至少有 3 个主要的库/框架用于创建类 REST 应用程序，更不用说将 JSON 解析为对象/类的库了。

此外，由于 REST 默认使用人类可读的格式，因此对于新手来说，它更容易调试和使用。这也会影响交付新特性的速度，并帮助用户应对代码中出现的错误。

长话短说，对 REST 风格应用程序的支持至少非常好。

在 Scala 中，甚至有一个叫做 Tapir 的工具。Tapir 允许用户抽象 HTTP 服务器，并编写可用于多个服务器的端点。

gRPC 本身为超过 8 种流行的编程语言提供了客户端库。这通常就足够了，因为这些库包含了制作 gRPC API 所需的所有内容。此外，一些库为 Java(通过 Spring Boot Starter)和 Scala 提供了更高的抽象。

另一件事是，REST 如今被认为是一个世界性的标准和构建服务的切入点，而 RPC 和 gRPC，特别是，尽管在这一点上有点过时，但仍然被视为一种新奇事物。

• 结果：REST 被更广泛地采用，并且有更多的库和框架。

（7）工具支持

以上已经介绍了库、框架和一般市场份额，所以在这一部分中介绍围绕这两种风格的工具。它意味着用于测试、性能/压力测试和文档的工具。

①自动化测试

首先，在 REST 的情况下，用于构建自动化测试的工具被构建到不同的库和框架中，或者是为了这个唯一目的而构建的独立工具，比如 REST-assured。

在 gRPC 的情况下，可以生成一个 stub 并将其用于测试。如果想要更严格，可以将生成的客户端作为一个单独的应用程序使用，并将其用作对实际服务进行测试的基础。

关于 gRPC 的外部工具支持，需要知道：

• Postman 程序对 gRPC 的支持。

• 在 IDE 中使用的 JetBrains HTTP 客户端也可以通过一些最低配置来支持 gRPC。

• 结果一：REST 获得胜利。然而，gRPC 的情况似乎有所改善。

②性能测试

在这里，REST 具有显著的优势，因为像 JMeter 或 Gatling 这样的工具使 REST API 的压力测试变得相当容易。

不幸的是，gRPC 没有这样的支持。在当前的 Gatling 版本中包含了 gRPC 插件，所以情况似乎正在好转。

然而到目前为止，只有一个名为 ghz 的非官方插件和库。这些都很好；它只是与 REST 的支持级别不同。

• 结果二：REST 的胜利；然而，gRPC 的情况似乎有所改善。

③文档

在 API 文档方面，随着 OpenAPI 和 Swagger 在整个行业被广泛采用并成为事实上的标准，REST 再次取得了胜利。几乎所有用于 REST 的库都能够以最小的努力或开箱即用的方式公开 Swagger 文档。

不幸的是，gRPC 没有这样的文档。

然而，问题是 gRPC 是否需要这样的工具。gRPC 在设计上比 REST 更具描述性，因此可能需要其他文档工具。

一般来说，带有 API 描述的.proto 文件比负责编写 REST API 代码的代码更具声明性和紧凑性，因此可能不需要 gRPC 提供更多文档。

• 结果三：REST 的胜利。然而，关于 gRPC 文档的问题是开放的。

④总体结果

这是 REST 的一次重大胜利。

总结

以下是 gRPC 和 REST 比较的最终得分表。

得出的结论是：gRPC 和 REST 的比较结果平分秋色，各有三场胜利，没有明显的赢家。

因此没有什么灵丹妙药，用户只需要考虑哪些类别可能对应用程序最重要，然后选择在大多数类别中获胜的方法。

善用工具

成功的前端工程师很会善用工具，这些年低代码概念开始流行，像国外的 Mendix，国内的 JNPF，这种新型的开发方式，图形化的拖拉拽配置界面，并兼容了自定义的组件、代码扩展，确实在 B 端后台管理类网站建设中很大程度上的提升了效率。

开源地址：https://www.jnpfsoft.com?infoq

代码量少，系统的稳定性和易调整性都会得到一定的保障。基于代码生成器，可一站式开发多端使用 Web、Android、IOS、微信小程序。代码自动生成后可以下载本地，进行二次开发，有效提高整体开发效率。同时，支持多种云环境部署、本地部署给予最大的安全保障，可以快速搭建适合自身应用场景的产品。

​