API 架构风格抉择：SOAP、REST、GraphQL 和 RPC 的特性、优势与局限

两个独立的应用程序需要一个中介来相互通信。因此，开发人员通常会构建桥梁——应用程序编程接口 (API) ——以允许一个系统访问另一个系统的信息或功能。

为了快速、大规模地集成应用程序，API 使用协议和/或规范来实现，以定义通过网络传递的消息的语义和语法。这些规范构成了 API 架构。

随着时间的推移，各种不同的 API 架构风格应运而生。每种架构风格都有其独特的数据交换标准化模式。选择之多，引发了关于哪种架构风格最佳的无休止的争论。

API 风格随时间变化

如今，许多 API 使用者将 REST 称为“宁静的 REST ”，并为 GraphQL 欢呼雀跃。而十年前，情况恰恰相反，REST 最终取代了 SOAP。这些观点的问题在于，他们片面地选择了一种技术本身，而没有考虑其实际属性和特性如何与实际情况相匹配。

在本文中，我们将保持客观，按照出现的顺序讨论四种主要的 API 风格，比较它们的优缺点，并重点介绍每种风格最适合的场景。

四种主要 API 样式比较

一、远程过程调用（RPC）

远程过程调用 (RPC)是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念，但将其置于 HTTP API 的上下文中。

最初的 XML-RPC 存在问题，因为确保 XML 负载的数据类型非常困难。因此，后来的 RPC API 开始使用更具体的JSON-RPC规范，该规范被认为是 SOAP 的更简单替代方案。gRPC是 Google 于 2015 年开发的最新 RPC 版本。凭借对负载均衡、跟踪、健康检查和身份验证的可插拔支持，gRPC 非常适合连接微服务。

RPC 的工作原理

客户端调用远程过程，将参数和附加信息序列化为消息，然后将消息发送到服务器。服务器收到消息后，会反序列化其内容，执行请求的操作，并将结果返回给客户端。服务器存根和客户端存根负责参数的序列化和反序列化。

远程过程调用机制

RPC 优点

简单直接的交互。RPC使用 GET 方式获取信息，其余操作则使用 POST 方式。服务器和客户端之间的交互机制归结为调用端点并获取响应。

易于添加功能。如果我们的 API 有新的需求，我们可以轻松添加另一个端点来执行此需求：1）编写一个新函数并将其置于端点之后；2）现在客户端可以访问此端点并获取满足设定需求的信息。

高性能。轻量级负载在网络上传输顺畅，性能出色，这对于共享服务器和在工作站网络上执行的并行计算至关重要。RPC 能够优化网络层，使其能够高效地处理每天在不同服务之间发送大量消息的情况。

RPC 缺点

与底层系统紧密耦合。API的抽象级别会影响其可重用性。API 与底层系统的耦合度越高，其对其他系统的可重用性就越低。RPC 与底层系统的紧密耦合使得系统内部函数与外部 API 之间无法建立抽象层。这引发了安全问题，因为底层系统的实现细节很容易泄露到 API 中。RPC 的紧密耦合使得可扩展性要求和松散耦合的团队难以实现。因此，客户端要么担心调用特定端点可能带来的副作用，要么会因为不理解服务器函数的命名方式而尝试弄清楚要调用哪个端点。

可发现性低。在 RPC 中，无法自检 API 或发送请求，也无法根据请求了解要调用的函数。

函数爆炸。创建新函数太容易了。因此，我们不是编辑现有函数，而是创建新函数，结果却得到了一大堆难以理解的重叠函数。

RPC 用例

RPC 模式大约在 80 年代开始使用，但这并不意味着它就过时了。像 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司都在内部使用 RPC 高性能变体来执行极高性能、低开销的消息传递。他们的大型微服务系统要求内部通信在短消息中清晰明了。

命令 API。RPC是向远程系统发送命令的正确选择。例如，Slack API 非常注重命令：加入频道、离开频道、发送消息。因此，Slack API 的设计者以类似 RPC 的风格对其进行了建模，使其精简、紧凑且易于使用。

面向内部微服务的客户专属 API。由于单一提供商和消费者之间直接集成，我们不想像 REST API 那样花费大量时间通过网络传输大量元数据。gRPC 和 Twirp 凭借高消息速率和高性能，是微服务的有力选择。gRPC 在底层使用 HTTP 2，能够优化网络层，并使其能够高效地在不同服务之间每天发送大量消息。但是，如果您的目标并非高网络性能，而是在发布高度差异化的微服务的团队之间建立稳定的 API 连接，那么 REST 能够满足您的需求。

二、简单对象访问协议 (SOAP)

SOAP是一种 XML 格式、高度标准化的 Web 通信协议。SOAP 由微软在 XML-RPC 一年后发布，它继承了 XML-RPC 的诸多特性。REST 随后出现，两者最初并行使用，但很快 REST 就赢得了普及。

SOAP 的工作原理

XML 数据格式拖累了诸多繁琐的流程，再加上庞大的消息结构，使得 SOAP 成为最冗长的 API 样式。

SOAP 消息由以下部分组成：

• 每封邮件开头和结尾的信封标签，
• 包含请求或响应的主体
• 如果消息必须确定任何细节或额外要求，则需要标头，以及
• 错误通知，告知在请求处理过程中可能发生的任何错误。

SOAP 消息示例。来源：IBM

SOAP API 逻辑以 Web 服务描述语言 (WSDL) 编写。该 API 描述语言定义了端点并描述了所有可执行的流程。这使得不同的编程语言和 IDE 能够快速建立通信。

SOAP 支持有状态和无状态消息传递。在有状态场景下，服务器会存储接收到的信息，这些信息可能非常庞大。但对于涉及多方和复杂事务的操作来说，这样做是合理的。

SOAP 的优点

语言和平台无关。内置的创建基于 Web 的服务功能允许 SOAP 处理通信，并使响应与语言和平台无关。

绑定多种传输协议。SOAP在传输协议方面非常灵活，可以适应多种场景。

内置错误处理。SOAP API 规范允许返回带有错误代码及其解释的“重试”XML 消息。

一系列安全扩展。SOAP与 WS-Security 协议集成，满足企业级事务质量要求。它确保事务内部的隐私性和完整性，同时允许在消息级别进行加密。

SOAP 消息级安全性：标头元素和加密正文中的身份验证数据

SOAP 的缺点

如今，许多开发人员由于多种原因，对于必须集成 SOAP API 的想法感到不安。

仅限 XML。SOAP消息包含大量元数据，并且仅支持请求和响应的详细 XML 结构。

重量级。由于 XML 文件很大，SOAP 服务需要大量带宽。

狭义的专业知识。构建 SOAP API 服务器需要深入了解所有相关协议及其严格限制的规则。

消息更新繁琐。需要额外添加或删除消息属性，僵化的 SOAP 模式会降低其采用速度。

SOAP 用例

目前，SOAP 架构最常用于企业内部或与其信任的合作伙伴之间的内部集成。

高度安全的数据传输。SOAP的严谨结构、安全性和授权功能使其成为在 API 和客户端之间执行正式软件合同的最佳选择，同时又能遵守 API 提供商和 API 消费者之间的法律合同。这正是金融机构和其他企业用户选择 SOAP 的原因。

三、表述性状态转移 (REST)

REST是一种不言自明的 API 架构风格，由一组架构约束定义，旨在被众多 API 消费者广泛采用。

当今最常见的 API 样式最初由 Roy Fielding 于 2000 年在其博士论文中描述。REST 使服务器端数据能够以简单格式（通常是 JSON 和 XML）表示。

REST 的工作原理

REST 的定义不像 SOAP 那样严格。RESTful 架构应遵循以下六个架构约束：

• 统一接口：允许以统一的方式与给定的服务器进行交互，无论设备或应用程序类型如何
• 无状态：处理请求所需的状态包含在请求本身中，并且服务器不存储与会话相关的任何内容
• 缓存
• 客户端-服务器架构：允许任何一方独立发展
• 应用程序的分层系统
• 服务器向客户端提供可执行代码的能力

事实上，有些服务只是在一定程度上符合 RESTful 风格。它们的核心是 RPC 风格，将大型服务分解为资源，并高效利用 HTTP 基础设施。但关键在于使用超媒体（HATEOAS），即超文本作为应用程序状态引擎的缩写。简单来说，这意味着 REST API 的每次响应都会提供链接到所有相关信息的元数据，这些信息与如何使用该 API 有关。这实现了客户端和服务器的解耦。因此，API 提供者和 API 使用者都可以独立发展，而不会妨碍彼此的通信。

Richardson 成熟度模型是实现真正完整且实用的 API 的目标

“HATEOAS 是 REST 的一个关键特性。它真正成就了 REST 的 REST 之美。由于大多数人不使用 HATEOAS，他们实际上使用的是 HTTP RPC。” Reddit上有人发表了这样激进的观点。事实上，HATEOAS 是 REST 最成熟的版本。然而，实现 HATEOAS 非常困难，因为它需要比目前常用和构建的 API 客户端更先进、更智能的 API 客户端。因此，即使是如今真正优秀的 REST API 也并非总能做到这一点。正因如此，HATEOAS 主要作为 RESTful API 设计长期发展的愿景。

当一个服务同时实现了 REST 和 RPC 的部分功能时，REST 和 RPC 之间可能确实存在一个灰色地带。REST 基于资源或名词，而不是基于动作或动词。

以动词为中心的 RPC 中的操作与以名词为中心的 REST 中的操作相反

在 REST 中，操作是使用 HTTP 方法完成的，例如 GET、POST、PUT、DELETE、OPTIONS 以及 PATCH。

资料来源：托马斯·戴维斯

REST 的优点

客户端与服务器解耦。REST尽可能地将客户端与服务器解耦，从而实现比 RPC 更好的抽象。具有抽象级别的系统能够封装其细节，从而更好地识别和维护其属性。这使得 REST API 足够灵活，能够随着时间的推移不断发展，同时保持系统稳定。

可发现性。客户端和服务器之间的通信描述了一切，因此无需外部文档即可了解如何与 REST API 交互。

缓存友好。REST复用了大量 HTTP 工具，是唯一允许在 HTTP 级别缓存数据的样式。相比之下，在任何其他 API 上实现缓存都需要配置额外的缓存模块。

支持多种格式。能够支持多种数据存储和交换格式，是 REST 目前成为构建公共 API 的主流选择的原因之一。

REST 的缺点

没有单一的 REST 结构。构建 REST API 没有绝对正确的方法。如何建模资源以及需要建模哪些资源将取决于具体场景。这使得 REST 在理论上简单，但在实践中却困难重重。

大负载。REST返回大量丰富的元数据，以便客户端仅从其响应中就能了解应用程序状态的所有必要信息。对于带宽容量巨大的大型网络管道来说，这种繁琐的操作并不是什么大问题。但情况并非总是如此。这正是 Facebook 在 2012 年提出 GraphQL 风格描述的关键驱动因素。

过度获取和不足获取问题。REST响应包含的数据过多或过少，通常需要发起另一个请求。

REST 用例

管理 API。这类 API 专注于管理系统中的对象，面向众多用户，是最常见的 API 类型。REST 有助于此类 API 拥有强大的可发现性、完善的文档，并且非常适合 REST 对象模型。

简单的资源驱动型应用。REST是一种连接不需要查询灵活性的资源驱动型应用的有效方法。

四、GraphQL 仅查询所需数据

它需要多次调用 REST API 才能返回所需的人员信息。因此，GraphQL 的发明就是为了改变现状。

GraphQL是一种描述如何发出精确数据请求的语法。对于包含大量相互引用的复杂实体的应用程序数据模型而言，实现 GraphQL 是值得的。

如何从 GraphQL 端点仅检索所需数据

如今，GraphQL 生态系统正在通过 Apollo、GraphiQL 和 GraphQL Explorer 等库和强大的工具不断扩展。

GraphQL 的工作原理

GraphQL 首先构建一个模式 (Schema)，它描述了 GraphQL API 中可能执行的所有查询以及它们返回的所有类型。模式构建非常困难，因为它需要模式定义语言 (SDL) 中的强类型支持。

在查询之前掌握了模式后，客户端可以验证其查询，确保服务器能够响应。到达后端应用程序后，GraphQL 操作将根据整个模式进行解释，并解析为前端应用程序的数据。向服务器发送一个大规模查询后，API 将返回一个 JSON 响应，其数据结构与我们请求的数据完全一致。

GraphQL 中的查询执行

除了 RESTful CRUD 操作之外，GraphQL 还具有允许从服务器获取实时通知的订阅功能。

GraphQL 的优点

类型化架构。GraphQL会提前公布其功能，从而提升其可发现性。通过将客户端指向 GraphQL API，我们就能了解有哪些可用的查询。

非常适合图形数据。适合包含深层链接关系的数据，但不适合平面数据。

无版本控制。版本控制的最佳实践是根本不对 API 进行版本控制。

虽然 REST 提供了多个 API 版本，但 GraphQL 使用单一的、不断发展的版本，该版本可以持续访问新功能并有助于实现更清洁、更易于维护的服务器代码。

详细的错误消息。与 SOAP 类似，GraphQL 提供发生的错误的详细信息。其错误消息包含所有解析器，并指向出错的确切查询部分。

灵活的权限。GraphQL允许选择性地公开某些函数，同时保留隐私信息。而 REST 架构不会分部分公开数据。要么全部公开，要么全部不公开。

GraphQL 的缺点

性能问题。GraphQL牺牲了复杂性来换取其强大功能。一个请求中嵌套过多字段可能会导致系统过载。因此，对于复杂查询，REST 仍然是更好的选择。

缓存复杂性。由于 GraphQL 不重用 HTTP 缓存语义，因此需要自定义缓存工作。

大量的开发前教育。由于没有足够的时间去了解 GraphQL 的利基操作和 SDL，许多项目决定遵循众所周知的 REST 路径。

GraphQL 用例

移动 API。在这种情况下，网络性能和单条消息负载优化至关重要。因此，GraphQL 为移动设备提供了更高效的数据加载方式。

复杂系统和微服务。GraphQL 能够将多系统集成的复杂性隐藏在其 API 背后。它聚合来自多个来源的数据，并将它们合并为一个全局模式。这对于随着时间推移而扩展的遗留基础设施或第三方 API 尤其重要。

五、哪种 API 模式最适合您的用例？

每个 API 项目都有不同的需求。通常，架构选择取决于

• 正在使用的编程语言，
• 你的开发环境，以及
• 您所能节省的资源，包括人力和财力。

了解每种设计风格的所有权衡后，API 设计人员可以选择最适合项目的设计风格。

由于紧密耦合，RPC 适用于内部微服务，但它不适用于强大的外部 API 或 API 服务。

SOAP 虽然麻烦，但其丰富的安全功能对于计费操作、预订系统和支付来说仍然是不可替代的。

REST 拥有最高的抽象度和最佳的 API 建模。但它往往负载更重，而且更繁琐——如果你在移动设备上工作，这将是一个缺点。

GraphQL 在数据获取方面取得了很大的进步，但并不是每个人都有足够的时间和精力去掌握它。

归根结底，尝试一些特定风格的小用例是有意义的，看看它是否适合你的用例并能解决你的问题。如果可以，请尝试扩展它，看看它是否适用于更多用例。

参考文章：