关于后端:API怎么选比较SOAPRESTGraphQL和RPC

咱们晓得，两个独自的应用程序须要中介程序能力互相通信。因而，开发人员通常会搭建桥梁（应用程序编程接口），以容许一个零碎拜访另一个零碎的信息或性能。

为了疾速、大规模地集成应用程序，API 是应用协定或标准实现的，这些协定或标准定义了通过网络传递的音讯的语义和语法。这些标准组成了 API 体系结构。

随着工夫的推移，不同的 API 架构格调曾经公布。每一种都有本人的标准化数据交换模式，抉择的丰盛引发了对于哪种架构格调是最好的无休止的争执。

明天，许多 API 消费者称 REST 为“安眠”，并为 GraphQL 欢呼，而十年前则相同，REST 是取代 SOAP 的赢家。这些观点的问题在于，他们是全面地抉择一种技术自身，而不是思考它的理论属性和个性如何与以后的状况相匹配。

在本文中，咱们将放弃主观的态度，探讨四大 API 格调的出场程序，比拟它们的强弱面，并强调它们各自最适宜的场景。

近程过程调用（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 的抽象层次有助于其可重用性。它与底层零碎的关系越严密，对其余零碎的可重用性就越低。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 具备较高的音讯速率和音讯性能，是微服务的无力案例。在 HTTP 2 的反对下，gRPC 可能优化网络层，每天在不同服务之间发送大量的音讯，效率十分高。然而，如果您的指标不是高网络性能，而是公布高度独特微服务的团队之间的稳固 API 分割，REST 将确保这一点。

简略对象拜访协定（SOAP）：使数据作为服务可用

SOAP是一种 XML 格局的、高度标准化的网络通信协定。SOAP 在 Microsoft 于 XML-RPC 发行一年后公布，从中继承了很多货色。当 REST 紧随其后时，它们首次并行应用，但很快 REST 博得了风行度比赛。

SOAP 如何工作

XML 数据格式背地拖着很多形式化的货色，配合宏大的音讯构造，使得 SOAP 成为最啰嗦的 API 格调。

SOAP 音讯包含：

• 蕴含申请或响应的注释
• 标头（如果音讯必须确定任何具体要求或额定要求），以及
• 故障告诉在整个申请处理过程中可能产生的任何谬误。

SOAP API 逻辑是用 Web 服务描述语言（WSDL）编写的。这种 API 描述语言定义了端点，形容了所有能够执行的过程，这使得不同的编程语言和 IDE 能够疾速建设通信。

SOAP 反对有状态和无状态消息传递。在有状态的状况下，服务器存储接管到的信息可能十分沉重。但这对于波及多方和简单交易的操作是正当的。

SOAP 长处

与语言和平台无关。创立基于 Web 的服务的内置性能容许 SOAP 解决通信并做出与语言和平台无关的响应。

绑定到各种传输协定。SOAP 在传输协定方面很灵便，能够适应多种状况。

内置错误处理。SOAP API 标准容许返回带有错误代码和解释的重试 XML 音讯。

许多平安扩大。与 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，即 Hypertext As The Engine of Application State 的缩写。基本上，这意味着每一个响应，REST API 都会提供元数据，链接到所有对于如何应用 API 的相干信息。这就是实现客户端和服务器解耦的起因。因而，API 提供者和 API 消费者都能够独立倒退而不障碍他们的交换。

“HATEOAS 是 REST 的一个要害个性。它是真正的 REST REST 的起因。因为大多数人没有应用 HATEOAS，他们实际上是在应用 HTTP RPC。”这是 Reddit 上表白的一些激进意见。事实上，HATEOAS 是 REST 最成熟的版本。然而，要实现这一指标，须要比目前通常应用和构建的 API 客户端先进得多的智能 API 是很艰难的。所以，现在即便是十分好的 REST API 也不肯定能做到。这也是为什么 HATEOAS 次要作为 RESTful API 设计的长期倒退愿景。

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

在 REST 中，应用 HTTP 办法，如 GET、POST、PUT、DELETE、OPTIONS，以及心愿的 PATCH，来实现事件。

REST 长处

解耦客户端和服务器。尽可能地将客户端和服务器解耦，REST 能够实现比 RPC 更好的形象。一个具备抽象层次的零碎，可能对其细节进行封装，以更好地辨认和维持其属性。这使得 REST API 具备足够的灵活性，能够随着工夫的推移而倒退，同时放弃一个稳固的零碎。

可发现性。客户端和服务器之间的通信形容了所有，因而不须要内部文档就能了解如何与 REST API 交互。

缓存敌对。重用了很多 HTTP 工具，REST 是惟一容许在 HTTP 层面上缓存数据的格调。相比之下，在任何其余 API 上实现缓存都须要配置一个额定的缓存模块。

反对多种格局。反对多种格局存储和替换数据的能力是目前 REST 成为构建公共 API 的支流抉择的起因之一。

REST 的毛病

没有独自的 REST 构造。构建 REST API 没有确切的正确办法。如何对资源进行建模，对哪些资源进行建模，将取决于每个场景。这使得 REST 在实践上很简略，但在实践中却很难。

大载荷。REST 会返回很多丰盛的元数据，这样客户端就能够仅仅从它的响应中理解利用状态的所有必要信息。对于一个领有大量带宽容量的大型网络管道来说，这种丰盛的元数据并不是什么大问题。但状况并不总是这样，这是 Facebook 在 2012 年推出 GraphQL 格调形容的要害驱动因素。

适度获取和获取有余问题。REST 响应蕴含的数据要么太多，要么不够，常常会产生对另一个申请的需要。

REST 用例

治理 API。最常见的 API 类型是专一于管理系统中的对象并面向许多使用者的 API。REST 使此类 API 具备弱小的可发现性和良好的文档，并且非常适合这种对象模型。

简略的资源驱动型应用程序。REST 是连贯不须要灵便查问的资源驱动型利用的贵重办法。

GraphQL：仅查问所需的数据

要调用 REST API 屡次能力返回所需信息，所以 GraphQL 的创造是为了扭转游戏规则。

GraphQL是一种形容如何进行准确数据申请的语法。对于具备大量互相援用的简单实体的应用程序数据模型来说，实现 GraphQL 是值得的。

现在，GraphQL 的生态系统正在通过 Apollo、GraphiQL 和 GraphQL Explorer 等库和弱小的工具进行扩大。

GraphQL 如何工作

GraphQL 从构建一个模式开始，它是对你在 GraphQL API 中可能进行的所有查问以及它们返回的所有类型的形容。构建模式很艰难，因为它须要在模式定义语言 (SDL) 中应用强类型。

在查问之前有了模式，客户能够依据模式来验证他们的查问，以确保服务器可能响应它。在达到后端利用时，GraphQL 操作会针对整个模式进行解释，并与前端利用的数据进行解析。API 向服务器发送一个大型查问，返回一个 JSON 响应，其中蕴含咱们申请的数据的确切形态。

除了 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 是数据获取方面的一大提高，但并不是每个人都有足够的工夫和精力去把握它。

在一天完结的时候，用一个特定的格调尝试几个小的用例是有意义的，看看它是否适宜你的用例并解决你的问题。如果的确如此，就尝试扩大，看看它是否适宜更多的用例。