RPC 和 REST 之间有什么区别？
远程过程调用（RPC）和 REST 是 API 设计中的两种架构风格。API 是允许两个软件组件使用一组定义和协议相互通信的机制。软件开发人员使用以前开发的组件或第三方组件来执行功能，因此他们不必从头开始编写所有内容。RPC API 允许开发人员在外部服务器中调用远程函数，就好像它们在软件本地一样。例如，您可以通过远程调用其他聊天应用程序上的消息收发函数来向应用程序添加聊天功能。相比之下，REST API 允许您在远程服务器上执行特定的数据操作。例如，您的应用程序可以使用 REST API 在远程服务器上插入或修改员工数据。
RPC 和 REST 有何相似之处？
远程过程调用（RPC）和 REST 都是设计 API 的方法。API 在现代 Web 设计和其他分布式系统中均不可或缺。它们允许两个独立的分布式应用程序或服务进行通信，而无需知道另一个应用程序或服务的内部工作原理。除了少量的数据交换外，这两个应用程序或服务彼此之间可能几乎没有关系。
API 也是程序后端（逻辑组件）与程序前端（显示组件）通信的常用机制。当您使用 API 而不是紧密耦合的集成来设计网页和 Web 应用程序时，您可以确保它们能够进行扩展而更改，同时只需要更少的代码重写。
接下来，我们将讨论 RPC 与 REST API 之间的其他相似之处。
抽象
虽然网络通信是 API 的主要目标，但较低级别的通信本身是从 API 开发人员那里抽象出来的。这使开发人员可以专注于功能而不是技术实施。
交流
REST 和 RPC 都使用 HTTP 作为底层协议。RPC 和 REST 中最常用的消息格式是 JSON 和 XML。JSON 因其可读性和灵活性而备受青睐。
跨语言兼容性
开发人员可以用他们选择的任何语言实施 RESTful 或 RPC API。只要 API 的网络通信元素符合 RESTful 或 RPC 接口标准，您就可以使用任何编程语言编写其余代码。
架构原则：RPC vs.REST
在远程过程调用（RPC）中，客户端在服务器上进行远程函数（也称为方法或过程）调用。通常，在调用期间会向服务器传递一个或多个数据值。
相比之下，REST 客户端则是请求服务器针对特定服务器资源执行操作。操作仅限于创建、读取、更新和删除（CRUD），并以 HTTP 动词或 HTTP 方法的形式传达。
RPC 侧重于函数或操作，而 REST 则侧重于资源或对象。
RPC 原则
接下来，我们将讨论 RPC 系统通常遵循的一些原则。但这些原则并不像 REST 那样标准化。
远程调用
RPC 调用是由客户端对远程服务器上的函数进行的，就像该函数是在本地调用到客户端的一样。
传递参数
客户端通常向服务器函数发送参数，与本地函数大致相同。
存根
函数存根同时存在于客户端和服务器上。在客户端上，它进行函数调用。在服务器上，它调用实际函数。
REST 原则
REST 原则是标准化的。REST API 必须遵循这些原则才能被归类为 RESTful。
客户端-服务器
REST 的客户端-服务器架构将客户端与服务器分离。该架构将客户端和服务器视为独立系统。
无状态
服务器不会保留两次客户端请求之间客户端状态的记录。
可缓存
客户端或中间系统可能会根据客户端是否指定了可以缓存响应来缓存服务器响应。
分层系统
中间系统可以存在于客户端与服务器之间。客户端和服务器都对中间系统一无所知，并像它们直接连接一样运行。
统一接口
客户端和服务器通过一组标准化指令和消息收发格式与 REST API 通信。资源由其 URL 标识，此 URL 称为 REST API 端点。
工作原理：RPC vs.REST
在远程过程调用（RPC）中，客户端使用 HTTP POST 按名称调用特定函数。客户端开发人员必须事先知道函数名称和参数，RPC 才能正常工作。
在 REST 中，客户端和服务器使用 GET、POST、PATCH、PUT、DELETE 和 OPTIONS 等 HTTP 动词来执行选项。开发人员只需要知道服务器资源 URL，而不必关心单个函数的名称。
下表显示了客户端用于在 RPC 和 REST 中执行类似操作的代码类型。
| 操作 |
RPC |
REST |
评论 |
| 向产品列表添加新产品 |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC 对函数使用 POST，REST 对 URL 使用 POST。 |
| 检索产品的详细信息 |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC 对函数使用 POST，并将参数作为 JSON 对象传递。REST 对 URL 使用 GET，并在 URL 中传递参数。 |
| 更新产品的价格 |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC 对函数使用 POST，并将参数作为 JSON 对象传递。REST 对 URL 使用 PUT，并将 URL 中的参数作为 JSON 对象传递。 |
| 删除产品 |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC 对函数使用 POST，并将参数作为 JSON 对象传递。REST 对 URL 使用 DELETE，并在 URL 中传递参数。 |
主要区别：vs.REST
下面列出了两者的更多区别。
开发时间
RPC 是在 1970 年代末和 1980 年代初开发的，而 REST 则是由计算机科学家 Roy Fielding 于 2000 年首次创造的术语。
操作格式
由于 HTTP 方法，REST API 拥有一组标准化服务器操作，但 RPC API 没有。某些 RPC 实施为标准化操作提供了框架。
数据传递格式
REST 可在同一 API 内传递任何数据格式和多种格式，如 JSON 和 XML。
但对于 RPC API 而言，数据格式由服务器选择，并且在实施过程中是固定的。您可以拥有特定的 JSON RPC 或 XML RPC 实施，但客户端没有灵活性。
省/市/自治区
在 API 的上下文中，无状态是指服务器不存储有关客户端先前交互的任何信息的设计原则。每个 API 请求都是独立处理的，服务器不依赖任何已存储的客户端状态来处理请求。
REST 系统必须始终是无状态的，但 RPC 系统可以有状态，也可以无状态，具体取决于设计。
何时使用：RPC 与REST
远程过程调用（RPC）通常用于调用服务器上需要操作结果的远程函数。当您需要进行复杂计算或者想要在服务器上触发远程过程时，可以使用它，并使该进程对客户端隐藏。
下面列出一些操作，对于这些操作而言，RPC 是不错的选择：
- 使用远程设备的摄像头拍照
- 在服务器上使用机器学习算法识别欺诈行为
- 在远程银行系统上将资金从一个账户转到另一个账户
- 远程重启服务器
REST API 通常用于针对服务器上的数据对象执行创建、读取、更新和删除（CRUD）操作。这使得 REST API 非常适用于需要统一公开服务器数据和数据结构的情况。
下面列出一些操作，对于这些操作而言，REST API 是一个理想选择：
- 将产品添加到数据库
- 检索音乐播放列表的内容
- 更新某人的地址
- 删除博客文章
为什么 REST 取代了 RPC？
虽然 REST Web API 已经成为当今的标准，但远程过程调用（RPC）并未消失。REST API 通常用于应用程序，因为它更易于开发人员理解和实施。但 RPC 仍然存在，并在更适合的应用场景中使用。
RPC 的现代实施（如 gRPC）现在更受欢迎。在某些应用场景下，gRPC 的性能优于 RPC 和 REST。它允许客户端-服务器间的流式通信，而非请求和响应数据交换模式。
差异摘要：RPC vs.REST
| RPC |
REST |
|
| 它是什么？ |
系统允许远程客户端调用服务器上的过程，就像它是本地过程一样。 |
一组规则，用于定义客户端和服务器之间的结构化数据交换。 |
| 用于 |
在远程服务器上执行操作。 |
针对远程对象创建、读取、更新和删除（CRUD）操作。 |
| 最适用于 |
当需要复杂计算或在服务器上触发远程进程时。 |
当需要统一公开服务器数据和数据结构时。 |
| 有状态 |
有状态或无状态。 |
无状态。 |
| 数据传递格式 |
在由服务器定义并在客户端上强制执行的一致结构中。 |
在由服务器独立确定的结构中。可在同一 API 中传递多种不同格式。 |
AWS 如何支持您的 API 需求？
Amazon Web Services（AWS）提供一系列服务和工具，可帮助 API 设计人员构建、运行和管理基于 API 的现代应用程序和服务。有关更多信息，请参阅有关在 AWS 上构建现代化应用程序的信息。
以下是可帮助您满足 API 需求的 AWS 服务示例：
- 使用 Amazon API Gateway，开发人员可以大规模地创建、发布和管理 API。借助 API Gateway，您可以构建针对容器化微服务架构和 Web 应用程序进行优化的 REST API。
- 弹性负载均衡（ELB）通过分配网络流量来提高应用程序可扩展性。它可以在微服务之间或启用 gRPC 的客户端和服务之间路由 gRPC 流量并对其进行负载平衡。这允许在软件架构中无缝管理 gRPC 流量，而无需更改客户的客户端或服务上的任何底层基础设施。
- Amazon Virtual Private Cloud（Amazon VPC）Lattice 是一项应用程序联网服务，可持续连接、监控和保护您的服务之间的通信。自动扩展计算和网络资源，以支持高带宽 HTTP、HTTPS 和 gRPC 工作负载。
立即创建一个账户，开始在 AWS 上使用 REST API 和远程过程调用（RPC）。
