gRPC 和 REST 之间有何区别？
gRPC 和 REST 是设计 API 的两种方式。API 是允许两个软件组件使用一组定义和协议相互通信的机制。在 gRPC 中，一个组件（客户端）调用另一个软件组件（服务器）中的特定函数。在 REST 中，客户端不会调用函数，而会请求或更新服务器上的数据。
什么是 gRPC？
什么是 RPC？
在 RPC 中，客户端-服务器通信的运行方式就像客户端 API 请求是本地操作一样，或者请求内容是服务器代码。
在 RPC 中，客户端向始终侦听远程调用的服务器上的进程发送请求。在请求中，它包含要调用的服务器函数，以及要传递的任何参数。RPC API 使用 HTTP、TCP 或 UDP 等协议作为其底层数据交换机制。
gRPC 与 RPC 有何不同？
gRPC 是一个通过多项优化实现传统 RPC 的系统。例如，gRPC 使用协议缓冲区和 HTTP 2 进行数据传输。
它还从开发人员那里抽象出数据交换机制。例如，另一种广泛使用的 RPC API 实施 OpenAPI 要求开发人员将 RPC 概念映射到 HTTP 协议。但是 gRPC 抽象了底层的 HTTP 通信。与其他 RPC 实施相比，这些优化使 gRPC 更快、更易于实现，并且对 Web 更友好。
什么是 REST？
REST 是一种软件架构方法，它定义了一组用于在软件组件之间交换数据的规则。它基于 HTTP，这是 Web 的标准通信协议。RESTful API 通过 HTTP 动词管理客户端和服务器之间的通信，如 POST、GET、PUT 和 DELETE 用于创建、读取、更新和删除操作。服务器端资源由称为端点的 URL 标识。
REST 的工作原理如下：
- 客户端请求在服务器上创建、修改或删除资源
- 请求包含资源端点，也可能包含其他参数
- 服务器做出响应，操作完成后，将全部资源返回给客户端
- 响应包含了 JSON 格式的数据和状态码
使用 REST 准则构建的 API 称为 RESTful API 或 REST API。
组织为什么要使用 gRPC 和 REST？
gRPC 和 REST 是两种不同的 API 开发方法。
API 的运作方式类似于通过菜单从餐厅点餐。在任何一家餐厅，顾客（客户端）都可以从菜单（API）订购食物，菜单上有一套固定的菜肴。这会传达给厨房（服务器），厨房（服务器）准备所要求的菜肴，并将其发送给顾客（客户端）。顾客不需要知道厨房是如何处理订单的，只需要知道他们想要得到什么。标准化的菜单格式意味着顾客和厨房知道该如何使用。
如果没有 API，那么将无法就不同的应用程序或软件服务的通信方式达成共识。两个独立应用程序的程序员每次都要进行沟通，确定如何构建数据交换。
存在不同类型的 API 架构，例如 gRPC 和 REST，因为不同的 API 架构可以更好地用于组织内的不同用例。API 设计人员必须根据系统要求选择其首选的客户端-服务器架构。
gRPC 和 REST 有何相似之处？
作为 API 架构方法，REST 和 gRPC 有一些固有的相似之处。
数据交换机制
两者都允许客户端和服务器这两个软件组件基于一组共享规则进行通信和交换数据。无论每个软件组件在内部如何运行，这些规则都适用。
基于 HTTP 的通信
两者都通过 HTTP 请求-响应机制传递数据，这是 Web 首选的高效通信协议。然而，在 gRPC 中，这一过程对开发人员而言是隐藏的；而在 REST 中，通信过程则更为明显。
实施灵活性
您可以使用多种编程语言实现 REST 和 gRPC。这种特性使它们在不同的编程环境中具有高度的可移植性。通过几乎完全通用的支持能力，实现了最佳的互操作性。
适用于可扩展的分布式系统
gRPC 和 REST 都使用以下内容：
- 异步通信，这样客户端和服务器可以在不中断操作的情况下进行通信
- 无状态设计，这样服务器不必记住客户端状态
这意味着开发人员可以使用 gRPC 和 REST 来构建具有大量并发请求的容错系统。您可以使用多个客户端构建可扩展的分布式系统。
架构原则：gRPC vs.REST
虽然 REST 和 gRPC 都提供类似的功能，但底层模型的架构差异很大。
通信模型
使用 REST API 时，客户端向服务器发送单个 REST API 请求，然后服务器发送单个响应作为回复。客户端必须等待服务器响应，然后才能继续操作。此机制是一种请求-响应模型，是一种单元数据连接（一对一）。
相比之下，如果使用的是 gRPC，那么客户端可以向服务器发送一个或多个 API 请求，这可能会导致服务器发出一个或多个回复。数据连接可以是单元（一对一）、服务器流（一对多）、客户端流（多对一）或双向流（多对多）。这种机制是一种客户端-响应通信模型，该模型因 gRPC 基于 HTTP 2 而可行。
服务器上的可调用操作
在 gRPC API 中，可调用的服务器操作由服务（也称为函数或过程）定义。gRPC 客户端调用这些函数，就像在应用程序内部调用函数一样。这被称为服务导向型设计。示例如下：
createNewOrder(customer_id, item_id, item_quantity) -> order_id
在 REST 中，客户端可以在 URL 定义的服务器资源上使用一组有限的 HTTP 请求动词。客户端自行调用资源。这被称为实体导向型设计。实体导向型设计与面向对象的编程方法很好地结合在一起。示例如下：
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
您可以用实体导向型方法设计 gRPC API，这并不是系统本身的限制。
数据交换格式
使用 REST API，软件组件之间传递的数据结构通常以 JSON 数据交换格式表示。可以传递 XML 和 HTML 等其他数据格式。JSON 易读且灵活，但必须对其进行序列化并翻译成编程语言。
相比之下，gRPC 默认使用协议缓冲区（Protobuf）格式，但是它也提供原生 JSON 支持。服务器在 proto 规范文件中使用协议缓冲区接口描述语言（IDL）定义数据结构。然后，gRPC 将该结构序列化为二进制格式，然后将其反序列化为任何指定的编程语言。这种机制比使用 JSON 更快，JSON 在传输过程中不会被压缩。与 JSON 使用的 REST API 不同，协议缓冲区不是人类可读的。
其他主要区别：gRPC vs.REST
其他主要区别：gRPC vs.REST
除了架构风格外，gRPC 和 REST 还有其他内在的差异。
客户端-服务器耦合
REST 是松散耦合，这意味着客户端和服务器不需要了解对方的实施状况。这种松耦合使得 API 更容易随着时间的推移而发展。这是因为更改服务器定义并不一定需要更改客户端的代码。
gRPC 是紧密耦合，这意味着客户端和服务器必须有权访问同一 proto 文件。对文件的任何更新都需要在服务器和客户端上进行更新。
代码生成
gRPC 提供一系列内置的客户端和服务器端原生代码生成功能。由于协议缓冲区编译器 protoc 的存在，可以生成多个语言的代码。在 proto 文件中定义结构后，gRPC 生成客户端和服务器端代码。代码生成可以减少 API 开发的时间。
另一方面，REST 不提供任何内置的代码生成机制，因此如果开发人员需要此功能，就必须使用其他第三方工具。
双向流式传输
gRPC 提供双向流式传输通信。这意味着客户端和服务器都可以在单个连接上同时发送和接收多个请求和响应。
REST 不提供此功能。
何时使用：gRPC vs.REST
REST 是目前最受欢迎的 Web 服务和微服务架构的 API 架构。REST 之所以受欢迎，是因为其实施简单，且具有数据结构映射、可读性和灵活性等特点。无论是用于 Web 服务开发还是内部微服务，新手程序员都可以很轻松地开始为其应用程序开发 RESTful API。
以下是 REST API 的应用场景：
- 基于 Web 的架构
- 面向公众的 API，便于外部用户理解
- 简单数据通信
与 REST 不同，gRPC 专为支持开发人员为分布式数据中心的微服务架构创建高性能 API 而设计。它更适合需要实时流式传输和大量数据加载的内部系统。当 API 不太可能随着时间的推移而发生变化时，gRPC 也非常适合包含多种编程语言的微服务架构。
gRPC API 更适合以下用例：
- 高性能系统
- 高数据负载
- 实时或流式传输应用程序
关于 Web 软件开发的说明
虽然 HTTP 是核心 Web 协议，但不同版本的 HTTP 在 Web 浏览器和 Web 服务器上的采用程度各不相同。
gRPC API 总是使用 HTTP 2，而 REST API 通常使用 HTTP 1.1，这两者并非同一个 HTTP 协议。虽然 HTTP 2 现在是一种常见的 Web 协议，但它不像 HTTP 1.1 那样具有通用的浏览器支持。对于需要支持 Web 应用程序的开发人员来说，这种受限的浏览器支持使得 gRPC 成为不那么有吸引力的选择。
差异摘要：gRPC 与REST
| gRPC API |
REST API |
|
| 它是什么？ |
一种基于远程过程调用（RPC）客户端-服务器通信模型创建和使用 API 的系统。 |
一组规则，用于定义客户端和服务器之间的结构化数据交换。 |
| 设计方法 |
服务导向型设计。客户端要求服务器执行某种服务或功能，这样的服务或功能可能会影响也可能不会影响服务器资源。 |
实体导向型设计。客户端要求服务器创建、共享或修改资源。 |
| 通信模型 |
多种选项，例如单元、一个服务器对多个客户端、一个客户端对多个服务器和多个客户端对许多服务器。 |
单元。单个客户端与单个服务器通信。 |
| 实施 |
需要客户端和服务器端都有 gRPC 软件才能运行。 |
您可以在客户端和服务器端以各种格式实现它，无需使用通用软件。 |
| 数据访问 |
服务（函数）调用。 |
有多个 URL 形式的端点，用于定义资源。 |
| 返回的数据 |
在协议缓冲区文件中定义的服务的固定返回类型中。 |
采用固定的结构（通常是 JSON），由服务器定义。 |
| 客户端-服务器耦合 |
紧密耦合。客户端和服务器都需要相同的协议缓冲区文件来定义数据格式。 |
松散耦合。客户端和服务器不知道内部详细信息。 |
| 自动生成代码 |
功能内置。 |
需要第三方工具。 |
| 双向流式传输 |
存在。 |
不存在。 |
| 最适合 |
高性能或数据密集型微服务架构。 |
资源定义明确的简单数据来源。 |
AWS 如何支持您的 gRPC 和 REST 需求？
Amazon Web Services（AWS）提供一系列服务和工具，可帮助 API 设计人员构建、运行和管理基于 API 的现代应用程序和服务。有关更多信息，请参阅有关在 AWS 上构建现代化应用程序的信息。
以下是可以支持您的 API 要求的 AWS 产品示例：
- 使用 Amazon API Gateway，开发人员可以大规模地创建、发布和管理 API。借助 API Gateway，您可以构建针对容器化微服务架构和 Web 应用程序进行优化的 RESTful API。
- 弹性负载均衡（ELB）通过分配网络流量来提高应用程序可扩展性。它可以在微服务之间或启用 gRPC 的客户端和服务之间路由 gRPC 流量并对其进行负载平衡。这可以在其架构中无缝引入 gRPC 流量管理，而无需更改客户的客户端或服务上的任何底层基础设施。
- Amazon Virtual Private Cloud（Amazon VPC）Lattice 是一项应用程序联网服务，可持续连接、监控和保护您的服务之间的通信。自动扩展计算和网络资源，以支持高带宽 HTTP、HTTPS 和 gRPC 工作负载。
立即创建账户，开始在 AWS 上使用 gRPC 和 REST。
