API已死，APIs万岁

在本文中，作者将重点介绍 REST API 的统治地位是如何衰退的，以及生态系统是如何走向民主的。API Is Dead – Long Live the APIs！

历史背景

正如我之前在博客中所描述的那样，在一个企业内部，随着时间的推移，技术会分层部署。许多较老的技术仍然能带来价值，使其远未过时。考虑到尽管许多企业正在经历数字化转型，但它们的旧层和深层中所包含的技术和相关数据仍然具有价值。不能简单地将它们移除，因为毕竟是在下面的层才能为放置新柱子奠定基础。这些层中的许多通常都具有遗留接口，如 CORBA、RMI、SOAP 等。

那么，为什么我们要在层上继续添加层呢？如果以古生物学家的身份来探讨这个问题，我们会采集一个核心样本，分析每一层；针对技术也可以来尝试这个方法，并深入到各个层次。每一层都代表一个历史视图，在最顶层 / 最外层，我们可以找到 REST，它是当今最普及的技术。就在 REST 之下，我们会遇到面向服务架构（Service Oriented Architecture，SOA）层。停下来思考下，为什么 REST 取代了 SOA ？虽然原因有很多，但可以说最主要的原因是 REST 极大地简化了客户端可访问性的问题，使用 REST，可以交换的是 JSON 而不是 XML，从而简化了在浏览器中的使用。

此外，REST 还有一个简化的方法，其动词 GET、PUT、POST 等允许使用简单的通用工具，比如 cURL 和 Postman。几乎用任何语言创建自己的客户端都非常简单。

另一方面

虽然该协议与平台无关，但是 SOAP 使用 XML，这使得在浏览器中使用它变得冗长而痛苦。此外，由 WS-* 标准增加的复杂性层意味着编写服务器端很容易，但编写客户端却很痛苦。客户端实现需要使用第三方工具以我们所选择的语言来生成客户端代码，这会产生繁重的依赖关系。

当我们深入研究技术层时，我们会发现类似的情况。SOAP 曾经也是王者，它取代了 CORBA 和 RPC 等技术。REST 从 SOAP 那里夺走了王位，而今天，REST 的王位正受到来自民主呼声的挑战。

谁是能从 REST 手中夺取王位的挑战者呢？有几个有追求的人在觊觎 REST 的王位。这些人可以分为三类：“服务器到客户端”、“基于事件”或“数据访问”家族。就像在《权力的游戏》中一样，挑战者可以按照他们的家族血统来划分（House Targaryen、House Lannister、House Stark 等）

“反向 API”家族：The House of “Reverse API”

这个家族的标志是电话，既是服务器调用客户端，而不能反过来调用。

Webhooks：Webhooks 有时被称为“反向 API”，因为调用的发起方是服务器而不是客户端；服务器将状态变更通知客户端。客户端应用程序注册一个回调 URL，当服务器上的资源发生状态变更时，就可以访问该 URL。客户端应用程序将收到状态变更的 HTTP 负载通知。Webhooks 是一种流行的基于事件的机制，该机制可以在网上找到（GitHub、Stripe、Twilio）。它们不是银弹，因为它们不提供有保证的交付，很少重试，可能会不同步，并且在事件量很大时（可能需要反压机制） 会给客户端带来很大的压力。

WebSocket：WebSocket 是一种传输协议，它通过一个 TCP 套接字连接在服务器和客户端之间建立一个持久的双向通信通道。当服务器到客户端或客户端到服务器需要近实时交换时，WebSocket 是一个不错的选择。这克服了 HTTP 请求 / 响应机制的限制（例如客户端轮询及相关的开销）。WebSocket 适用于需要实时更新的应用程序，因为服务器可以在连接上随时推送数据。所有现代浏览器都支持 WebSocket。

SSE： 服务器发送事件（Server-Sent Events，SSE）是一种服务器推送技术，它允许客户端通过带有内置自动重连机制的 HTTP 连接接收来自服务器的自动更新。服务器发送事件 EventSource API 作为 HTML5 的一部分被进行了标准化。SSE 是通过传统 HTTP 发送的，这意味着它不需要特殊的协议或服务器实现即可正常工作。另一方面，WebSockets 需要全双工连接和新的 Web Socket 服务来处理协议。SSE 适用于不需要从客户端发送数据，但需要通过某些服务器操作进行更新（例如股票行情、共享设施更新、好友状态更新等）的场景。

“事件驱动”家族：The House of “Event-Driven”

这个家族的标志是 Kafka 图标，因为它是“事件驱动”的主导者。

这个家主要由三个字符组成，即两个基于提交日志 Apache Kafka 和 NATS 的消息传递系统，以及 RabbitMQ 的消息队列。这些技术已经成为基于异步事件的微服务架构的实际支柱。基于事件消息传递的架构会导致服务之间的极度松散耦合，这对于事件驱动系统非常有用。在这些架构中，诸如 CQRS（命令查询职责分离）和事件源等不同的设计模式非常流行。因为 JSON 太冗长，发送到队列的消息使用 Proto Buf、Avro 或 Thrift 定义，事件将被内部微服务消费。

由于基于事件的系统是异步的，因此系统本身将具有最终一致性。这导致开发人员不得不处理服务之间的不一致数据。根据所使用的消息传递主干，可能必须考虑接收重复事件、无序事件或丢失事件（保证交付）的处理。与传统的 REST API 相比，可用于基于事件的开发（设计、调试、测试、监控）工具更加不成熟。

有两个新兴项目值得跟踪和投入：

• 由云原生基金会（Cloud Native Foundation，CNCF）孵化的 CloudEvents 项目正在尝试定义与供应商无关的事件格式，以便在不同的云系统之间进行转换。
• AsyncAPI 的目标是使事件驱动的架构更简单，并且像 REST API 一样为开发人员所熟悉，它将包括文档、代码生成、发现和事件管理。

gRPC 家族：The House of gRPC

gRPC 的名称中包含了一些线索；“g” 来自 Google 和 RPC，因为它是为远程过程调用（RPC）而设计的。这是 CNCF 的一个顶级项目。gRPC 通常在组织内部使用（即在微服务架构中），这样我们可以控制消费者和提供者。因为它使用了 HTTP 2.0，gRPC 相较于传统的 HTTP 1.1 REST 调用有较高的性能。服务定义是使用了 Proto Buf ，由此，可以用多种语言生成客户端和服务端存根。gRPC 支持双向流和可插拔的身份验证机制。

“GraphQL”家族：The House of “GraphQL”

GraphQL：GraphQL API 适用于移动应用程序，并且有助于避免使用 REST API 时出现的闲聊问题。借助 GraphQL，客户端可以确定它们所需的数据、所需怎样的数据以及所需的数据格式，而无需遍历多个 REST 请求 / 响应来查找应用程序所需的资源。这将减少调用客户端所需建立的网络连接次数，并确保它们只检索所需的数据。如果客户端是移动应用程序或单页应用程序（single-page application，SPA），则可以提供更好的用户体验。2015 年，Facebook 公开发布了 GraphQL 规范和参考实现。但今天，GraphQL 的管理工作由 GraphQL 基金会负责。

为什么说GraphQL是API的未来？

“OData”家族：The house of “OData”

OData：OData（开放数据协议）是一个 OASIS 标准，它定义了构建和使用 RESTful API 的最佳实践。它最初是由微软在 2007 年开发的。OData 是 HTTP、REST 和 JSON 之上的一组通用约定。如果采用这些约定，则意味着 API 提供者最终将以一种标准且一致的方式来处理诸如查询、分页、排序和过滤 API 之类的问题。正是由于这些约定，如果我们看到了一个 OData 服务，那么我们也就看到了所有服务，并且实现消费应用程序变得更加容易。OData API 经常出现在运行 Microsoft 和 SAP 服务的生态系统中。

“IoT”家族：The House of “IoT”

鉴于物联网设备的爆炸性增长，这个家族牢牢地坐落在亿万富翁俱乐部里。

MQTT（消息队列遥测传输）： 是一种基于发布 - 订阅的 ISO 标准消息传递协议。它在 TCP/IP 协议之上工作。设计它是用于与需要“小代码占用”的远程位置的连接或我们需要限制网络带宽的情况。因此，对于带宽昂贵且所需开销最小的嵌入式系统等客户端来说，它是一种完美的协议。

AMQP（高级消息队列协议） 是异步通信中最流行的协议之一。RabbitMQ 和 ActiveMQ 是一些流行实现，或者有像 AWS MQ 这样的托管解决方案。AMQP 是面向消息中间件的开放标准应用层协议。AMQP 的主要特点是消息定向、排队、路由、可靠性和安全性。与 MQTT 相比，AMQP 具有更多特性，因此，它更适合在需要更高处理和内存要求的客户端系统上运行。因此，它被视为一个相当繁重的协议，在物联网的传感器 / 嵌入式世界中不能很好地发挥作用。

结论

正如本文所示，REST API /Services 的君主统治已经过去了。所需的 API 技术生态系统将专用于消费客户端应用程序的需求。生态系统中不会只有一个赢家，而是有许多赢家，这取决于客户所需的经验。没有一项技术会永远坐上王位上，这是一种民主，客户决定将由谁来代表他们！

API 已死了——API 万岁！

API is dead,long live the APIs