分布式系统之间的通信方式对其效率、可靠性和整体功能至关重要。 REST（具象状态传输）和RPC（远程过程调用）是众所周知的通信范式。
REST 和 RPC 允许不同的系统或组件相互通信。 然而，它们在理念、设计和应用方面有着根本的不同。
本教程重点介绍 REST 和 RPC 之间的区别，揭示它们的历史、原理、优点和缺点。
REST 和 RPC 起源的差异凸显了 Web 通信的演变，并凸显了两者都旨在解决的挑战和背景。
RPC的概念可以追溯到分布式计算的早期。 系统需要一种方法在远程计算机上执行过程或函数，基本上像本地过程一样调用它。
随着Sun Microsystems开发的SunRPC的推出，RPC系统在20世纪80年代开始初具规模。 随着互联网的发展，RPC的功能不断增强。 这导致了 xml-rpc 等变体的开发，它允许使用 xml over http 和后来的 json-rpc 进行远程调用。
REST并不关注RPC等操作或方法，而是以资源为中心。 Fielding 强调使用 Web 的固有功能，特别是无状态请求和 HTTP 的标准化方法。
鉴于其简单性和与网络原则的一致性，REST迅速获得了关注。 它成为 Web 上公共 API 的标准。 虽然 RESTful 原则仍然非常普遍，但越来越多的人正在转向更灵活、更高效的协议，尤其是在 REST 可能不是最佳的特定用例中。
REST是一种架构风格。 它提供了一组约束，使系统能够实现性能、可伸缩性和可修改性等属性。
REST的核心是表示和操作网络上的资源。 资源可以是任何内容（对象、服务、数据），并由其 URI 唯一标识。
RPC 是一种协议，程序可以使用该协议从另一台计算机上的程序请求服务。 它允许程序使过程或子程序在另一个地址空间（通常是共享网络上的另一台计算机）上执行。 这类似于在不同计算机上存在的对象上调用方法。
数据传输的方式和用于此类通信的约定使 REST 和 RPC 截然不同。 让我们剖析它们各自的通信模式。
REST依靠其标准化的方法集与HTTP协议的强大功能和简单性进行通信。 这些标准 http 谓词确保了交互的一致性和可接受性。
由于无状态通信，从客户端到服务器的每个请求都必须包含理解和处理该请求所需的所有信息。 这使得交互清晰明了，并且无需在服务器上维护会话状态。
RPC 的模型更多的是关于调用操作。 它的方法调用更详细，并指示了具体的进程。
RPC 类似于调用函数。 客户端指定要执行的进程以及参数，服务器返回结果。 这看起来比基于资源的方法更直接、更精细。
需要注意的一个重要方面是，由于 RPC 的过程性质，它们可能看起来是紧密耦合的。 grpc 等现代实现在构建时考虑了灵活性和效率，允许更具可扩展性和松散耦合的系统。
系统如何识别和处理与之交互的数据或服务是其设计和功能的核心。 REST 和 RPC 范式对此问题有不同的方法。
在 RESTful 世界中，一切都围绕着资源的概念。 RESTful 系统中的每个资源都由其 URI 唯一标识。 这种设计选择提供了一种简单的方法来定位、操作网络上的实体并与之交互。
在REST中，它不仅仅是关于识别资源，而是关于我们如何表示它。 常见的表示形式包括 JSON 和 XML 等。 这个想法是使用这些表示形式通过标准 HTTP 方法与资源进行交互。
RPC 围绕调用过程或方法展开。 在 RPC 中，我们调用服务器提供的特定方法。 方法名称和参数是请求的核心。 在REST中没有像URI这样的标准。 相反，方法名称及其签名成为定义方面。
参数可以按名称或位置传递，方法命名通常反映它试图在服务器端实现的目标。 虽然这可以看作是灵活的，但它也可能导致版本控制和随时间推移更改方法签名的挑战。
传输数据的表示和结构在通信的清晰度、效率和性能方面起着关键作用。 REST 和 RPC 对此有不同的策略。
REST独立于数据格式，但有一些流行的约定在业界被广泛采用。 大多数 RESTful 服务都使用 JSON，因为它轻量级且易于使用。 XML在早期的实现中更受欢迎，特别是在基于SOAP的服务中，但对JSON的支持已经下降。
REST的美妙之处在于，我们可以选择最适合我们需求的表示形式。 例如，虽然 JSON 和 XML 很常见，但某些系统可能使用 YAML、HTML 甚至自定义格式。
RPC 中数据的格式很大程度上取决于所使用的 RPC 协议的类型和规范。
在较新的 RPC 协议（如 GRPC）中，非常强调性能。 例如，Protobuf 比 JSON 和 XML 更小、更快。 这可以显著提高性能，尤其是在具有高吞吐量要求的系统中。
优质作者名单