两个单独的应用程序需要中介程序才能相互通信。 因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。
为了快速、大规模地集成不同的应用程序，API 使用协议或规范来定义那些通过网络传输的消息的语义和信息。这些规范构成了 API 的体系结构。
在过去，人们已经发布了多种不同的 API 架构风格。每个架构风格都有它独有的标准化数据交换的模式。这一系列的 API 架构风格的选项，引发了大量的关于哪种架构风格才是最好的争论。
不同时间的 API 架构风格，图源：Rob Crowley
今天，许多 API 的使用者将 REST 称作“消亡的 REST”（REST in peace），并且为 GraphQL 感到欢欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的赢家。这些观点的问题在于，它们的出发点只是为某种技术背书，而不是去考虑它实际的属性和特性如何与当前的需求相匹配。
四种 API 架构风格
RPC：调用另一个系统的函数
远程过程调用是一种允许在不同上下文中远程执行函数的规范。 RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。
最初的 XML-RPC 是存在问题的，因为很难确保 XML 有效负载的数据类型。因此，后来 RPC API 开始使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。
RPC 的工作机制
客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。
远程过程调用的机制，图源：Guru99
RPC 的优势
简单直接的交互。RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。
易于添加新函数。如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。
高性能。轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。
RPC 的不足
和底层系统紧密耦合。API 的抽象级别有助于其可重用性。API 与基础系统的耦合越紧密，对其他系统的可重用性就越差。 RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立抽象层。这很容易引起安全问题，因为关于基础系统的细节实现很容易会泄漏到 API 中。
RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么会担心调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，因为客户端不了解服务器如何命名其函数。
可发现性低。在 RPC 中，无法对 API 进行检验总结，或者发送请求来开始理解根据需求应该调用哪个函数。
函数爆炸性增长。创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能重叠的函数。
RPC 的用例
RPC 模式在八十年代开始使用，但这并不意味着它已经过时了。诸如 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 格式的、高度标准化的网络通讯协议。在 XML-RPC 发布的一年后，SOAP 由微软发布、并继承了许多 XML-RPC 的特性。在 REST 紧随其后发布，一开始它们是被同时使用，但很快 REST 赢得了这次比赛，成为了更流行的协议。
SOAP 的工作机制
XML 数据格式拖累了很多数据规范。伴随着大量的消息结构，XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。
SOAP 的消息由这些部件组成：
一个信封标签：用于开始和结束每条消息
包含请求或响应的正文
一个标头：用于表示消息是否由某些规范或额外要求的来确认
故障通知：包含了可能在请求处理过程只能够发生的任何错误
一个 SOAP 消息的例子，图源：IBM
SOAP API 的逻辑由 Web 服务描述语言（WSDL）编写。该 API 描述语言定义了端点并描述了可以执行的所有过程。这使得不同的编程语言和 IDE 能够快速建立通信。
SOAP 支持有状态和无状态消息传递。在有状态的情况下，服务器存储接收到的信息可能非常繁琐复杂。 但这对于涉及多方和复杂交易的操作是合理的。
SOAP 的优势
独立于语言和平台。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。
绑定到各种协议。SOAP 在适用于多种场景的传输协议方面是十分灵活的。
内置错误处理。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。
一系列的安全拓展。SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。
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 在其博士论文中提出的。REST 使得服务端的数据可用，并以简单的格式（通常是 JSON 和 XML）来表示它。
REST 的工作机制
REST 的定义并不像 SOAP 那样严格。RESTful 体系结构应该遵守如下六个体系结构约束：
统一接口：无论设备或应用程序类型如何，都可以采用统一的方式与给定的服务端进行交互；
无状态：请求本身包含处理该请求所需要的状态，并且服务端不存储与会话相关的任何内容
缓存
客户端-服务器体系结构：允许双方独立发展
应用程序的层级系统
服务端向客户端提供可执行代码的能力
实际上，某些服务仅在某种程度上是 RESTful 的。而它们的内核采用了 RPC 样式，将较大的服务分解为资源，并有效地使用 HTTP 基础结构。但 REST 的关键部分是超媒体（又称 HATEOAS），是超文本作为应用程序状态引擎（Hypertext As The Enginer Of Application State）的缩写。基本来说，这意味着 REST API 在每个响应中都提供元数据，该元数据链接了有关如何使用该 API 的所有相关信息。这样便可以使客户端和服务端解耦。因此，API 提供者和 API 使用者都可以独立发展，而这并不会阻碍他们的交流。
理查森成熟度模型作为实现真正完整且有用的 API 架构的目标。图源：Kristopher Sandoval
“HATEOAS 才是 REST 的关键功能，因为它真正使得 REST 成为 REST。 但由于大多数人不使用 HATEOAS，因此他们实际上是在使用 HTTP RPC。”这是 Reddit 上表达的一些激进观点。 确实，HATEOAS 是 REST 的最成熟版本。
但是，这非常难以实现，因为这要求 API 客户端要比它们如今构建和使用的方式变得更先进和智能得多。因此，即便是如今非常好的 REST API 也不一定总是能做到这一点。 这就是为什么 HATEOAS 主要是作为 RESTful API 设计的长期开发的愿景而存在。
当服务端实现 REST 的某些功能和 RPC 的某些功能时，在 REST 和 RPC 之间确实可能存在这样一个灰色区域。 但 REST 是基于资源或名词的，而不是基于动作或动词。
以动词为中心的 RPC 模型和以名词为中心的 REST 模型中的操作对比
在 REST 中，使用例如 GET、POST、PUT、DELETE、OPTIONS 可能还有 PATCH 等 HTTP 方法来完成操作。
图源：Thomas David
REST 的优势
客户端和服务端的解耦：由于 REST 尽可能地解耦了客户端和服务端，REST 相较于 RPC 可以提供更好的抽象性。具有抽象级别的系统能够封装其实现细节，以更好的标示和维持它的属性。这使得 REST API 足够灵活，可以随着时间的推移而发展，同时保持稳定的系统。
可发现性：客户端和服务端之间的通信描述了所有内容，因此不需要外部文档即可了解如何与 REST API 进行交互。
缓存友好：REST 重用了许多 HTTP 工具，也是唯一一种可以在 HTTP 层面上缓存数据的 API 架构风格。 与其相对的是，在任何其他 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 端点仅获取所需要的数据，图源：Mohit Tikoo
如今，GraphQL 的生态系统正在蓬勃发展，出现了例如 Apollo、GraphiQL 和 GraphQL Explorer 等强大的库和工具。
GraphQL 的工作机制
GraphQL 从构建模式（Schema）开始。模式是对于用户可以在 GraphQL API 中进行的所有查询及其返回的所有类型的描述。模式构建非常困难，因为它需要使用模式定义语言（SDL）进行强类型化。
因为在客户端进行查询之前已经定义好了模式，所以客户端可以验证其查询语句，以确保服务端能够对查询语句进行响应。在查询语句到达后端应用程序时，GraphQL 操作将根据整个模式进行解释，并向前端应用程序返回解析到的数据。API 向服务端发送一个庞大的查询，该 API 返回一个仅包含我们所需数据的 JSON 响应。
GraphQL 的查询语句执行，图源：Jonas Helfer
除了包含 RESTful 的 CRUD 操作，GraphQL 还有订阅（subscriptions）机制，允许接收来自服务端的实时通知。
GraphQL 的优势
具有类型的模式：GraphQL 提前公开了它能做什么，从而提高了其可发现性。通过将客户端指向 GraphQL API，我们可以发现什么查询语句是可用的。
没有版本控制：版本控制的最佳实践是不要对 API 进行版本控制。
尽管 REST 提供了不同的 API 版本，GraphQL 使用的是不断更新的单一版本，这使用户可以持续访问新功能，并有助于提供更整洁、更可维护的服务器代码。
详细的错误消息：GraphQL 以类似于 SOAP 的方式提供所发生错误的详细信息。 它的错误消息包括所有解析器，并指向确切的发生故障时的查询部分。
灵活的权限：GraphQL 允许选择性地公开某些功能，同时保留私人信息。而相对应的是，REST 体系架构不能仅显示部分数据，要么是全部数据，要么是没有数据。
GraphQL 的不足
性能问题。 GraphQL 权衡了复杂性，来实现其强大功能。 一个请求中的嵌套字段太多会导致系统过载。 因此，对于复杂的查询，REST 仍然是更好的选择。
缓存复杂度。 由于 GraphQL 不再使用 HTTP 缓存语义，因此使用者需要额外自定义缓存。
大量的预开发教育。 由于没有足够的时间来了解 GraphQL 的某个操作和 SDL，因此许多项目决定采用众所周知的 REST 方法。
GraphQL 的用例
移动 API。 在这种情况下，网络性能和单个消息有效负载优化很重要。 因此，GraphQL 为移动设备提供了更有效的数据加载方式。
复杂的系统和微服务。 GraphQL 能够隐藏其 API 背后的多个系统集成的复杂性。 GraphQL 从多个地方聚合数据，并将它们合并为一个全局的模式。 对于随时间推移而逐渐扩展的遗留基础架构或第三方 API 来说，这尤其重要。
哪种 API 模式最适用你的用例？
每个 API 项目都有不同的限制和需求。通常，API 架构的选择取决于：
所使用的编程语言，
你的开发环境，以及
你的资源预算，包括人力资源和财务资源。
在了解了每种设计风格的利与弊之后，API 设计人员可以选择最适合项目的那一种。
具有强耦合性的 RPC 很适用于内部微服务，但它对外部 API 或者 API 服务而言不是一个好的选择。
SOAP 的使用有些麻烦，但它强大的安全拓展使它在计费操作、预订系统和支付方面是无可替代的。
REST 是针对 API 的最高级别的抽象和最佳模型。但它往往会有些“啰嗦”而增加系统的负担 —— 如果你使用的是移动设备，这是个问题。
GraphQL 在数据获取方面向前迈出了一大步，但并不是每个人都有足够的时间后精力来掌握它。
归根结底，去针对一些小型的用例来尝试某种特定 API 架构，并去了解它是否适合你的用例以及是否解决了你的问题，这样做是比较合适的。如果它适用于你的用例，就可以尝试扩展并查看它是否适用于更多的用例。
原文链接：
