RPC和REST对比

当我们对比RPC和REST时，其实是在对比RPC风格的API和REST风格的API，后者通常成为RESTful API。

远程过程调用（RPC）和 REST 都是设计 API 的方法。API 在现代 We b 设计和其他分布式系统中均不可或缺。它们允许两个独立的分布式应用程序或服务进行通信，而无需知道另一个应用程序或服务的内部工作原理。除了少量的数据交换外，这两个应用程序或服务彼此之间可能几乎没有关系。

API 也是程序后端（逻辑组件）与程序前端（显示组件）通信的常用机制。当您使用 API 而不是紧密耦合的集成来设计网页和 We b 应用程序时，您可以确保它们能够进行扩展而更改，同时只需要更少的代码重写。

接下来，我们将讨论 RPC 与 REST API 之间的其他相似之处。

抽象
虽然网络通信是 API 的主要目标，但较低级别的通信本身是从 API 开发人员那里抽象出来的。这使开发人员可以专注于功能而不是技术实施。
交流
REST 和 RPC 都使用 HTTP 作为底层协议。RPC 和 REST 中最常用的消息格式是 JSON 和 XML。JSON 因其可读性和灵活性而备受青睐。
跨语言兼容性
 开发人员可以用他们选择的任何语言实施 RESTful 或 RPC API。只要 API 的网络通信元素符合 RESTful 或 RPC 接口标准，您就可以使用任何编程语言编写其余代码。

在远程过程调用（RPC）中，客户端在服务器上进行远程函数（也称为方法或过程）调用。通常，在调用期间会向服务器传递一个或多个数据值。

相比之下，REST 客户端则是请求服务器针对特定服务器资源执行操作。操作仅限于创建、读取、更新和删除（CRUD），并以 HTTP 动词或 HTTP 方法的形式传达。

RPC 侧重于函数或操作，而 REST 则侧重于资源或对象。

接下来，我们将讨论 RPC 系统通常遵循的一些原则。但这些原则并不像 REST 那样标准化。

REST 原则是标准化的。REST API 必须遵循这些原则才能被归类为 RESTful。

在远程过程调用（RPC）中，客户端使用 HTTP POST 按名称调用特定函数。客户端开发人员必须事先知道函数名称和参数，RPC 才能正常工作。

在 REST 中，客户端和服务器使用 GET、POST、PATCH、PUT、DELETE 和 OPTIONS 等 HTTP 动词来执行选项。开发人员只需要知道服务器资源 URL，而不必关心单个函数的名称。

下表显示了客户端用于在 RPC 和 REST 中执行类似操作的代码类型。
在这里插入图片描述

远程过程调用（RPC）和 REST 都是用于设计相应的客户端和服务器系统接口以通过互联网进行通信的方法。但两者的结构、实施和基本原则各不相同。使用 REST 设计的系统称为 RESTful API，而使用 RPC 设计的系统就是 RPC API。
下面列出了两者的更多区别。

开发时间
RPC 是在 1970 年代末和 1980 年代初开发的，而 REST 则是由计算机科学家 Ro y Fie ld in g 于 2000 年首次创造的术语。
操作格式
由于 HTTP 方法，REST API 拥有一组标准化服务器操作，但 RPC API 没有。某些 RPC 实施为标准化操作提供了框架。
数据传递格式
REST 可在同一 API 内传递任何数据格式和多种格式，如 JSON 和 XML。
但对于 RPC API 而言，数据格式由服务器选择，并且在实施过程中是固定的。您可以拥有特定的 JSON RPC 或 XML RPC 实施，但客户端没有灵活性。
省/市/自治区
在 API 的上下文中，无状态是指服务器不存储有关客户端先前交互的任何信息的设计原则。每个 API 请求都是独立处理的，服务器不依赖任何已存储的客户端状态来处理请求。