Build RealTime RESTful API

 

当前实时生成和消耗的数据比例正在呈指数级增长。据 IDC 预测，到 2025 年全球生成的所有数据中有 1/3 将是实时的。 

 

然而，人们对实时 API、事件驱动 API 或流 API 所指的术语仍没有达成一致或共识，它们经常互相使用。

 

假如一个 JSON REST API 实时统计数据，然后被推送到服务器进行存储，一个 JSON REST API 调用，多个不同的客户端应用可以在数据存储后实时接收该数据，要达到服务器在更新到达时推送更新，我们可以使用轮询或者 websocket，如 Socket.io。在数据存储事件下放置一个发出事件，以立即发送已存储的数据。

 

Real-Time APIs 通常是指即时的功能或交互，数据从生产者流向消费者的 API 设计都在尽可能短的时间内发生。它通常包括以下 4 种模式：

 

• Event-Driven API（事件驱动，架构模式）
• Streaming API（流式处理，消费者模式）
• Pub/Sub API（发布/订阅，消息模式）
• Push API（推送，生产者模式）

 

1、流式传输 API

 

Streaming 是一种消费者模式，它描述来消费者如何通过流接收事件。

 

流式 API 通常会通过以下方式解决数据完整性问题：

 

• 消息排序：确保消息按照发布的顺序传递。
• 流连续性/恢复：断开连接后，在设定的时间段内从断开的点恢复。
• 连续的序列号：一系列简单的 “ACK” 或 “NACK” 响应，每个都寻址一个连续的消息序列。

Apache Kafka 为系统提供遵循该模型的流式 API。

 

 

2、发布/订阅 API。

 

发布/订阅是一种被广泛使用的消息传递设计模式。它解决了服务器的松散解耦问题。

 

这种模式通过在消息总线中的通道上发布消息来运行，订阅者可以根据这些通道监听事件。

 

 

3、推送 API。

 

推送是一种生产者消息传递模式，数据通过连接向上游推送，而不是请求/响应模式中使用的 Pull 机制。

 

一个通知可能会通过推送 API 发送给多个系统，从而在几百毫秒内向全球发送数百万条消息。

 

Push 也可以使用 Webhook 触发新请求，推送订阅的过程中，生产者需要联系消费者。

 

webhook 是 2000 年引入的概念，当时在线服务提供商如电子邮件、短信电话、支付网关等兴起，为了使不同的系统和应用程序能够相互通知事件，开发人员大多使用长轮询的方式。轮询需要应用程序定期向服务器发送请求，以获取任何远程发生事件的状态更新。除了带宽问题，另一个问题是它不能可靠地实时提供更新，除非客户端应用程序以极高的频率获取 API。

Webhook 被引入作为第三方服务提供商和消费者/应用程序提供商之间的通信桥梁，用于在服务提供商端发生事件时将回调数据发送回应用程序提供商，从而实现有效的实时消息传递。

 

webhook 是用户定义的 HTTP 回调，当外部网站或服务上发生特定事件时触发。

 

当您在应用程序中构建通知功能和事件驱动响应时，它们特别有用。Webhook 使两个远程应用程序之间的关键数据保持同步。

 

例如，您的电子商务应用程序可以使用 webhook 确保在第三方支付网关收到客户付款时收到通知。您的时事通讯活动可能会使用 webhook 通知您的营销人员任何后续电子邮件活动，然后根据需要触发其他功能。如果电子商务零售商使用第三方支付网关，则“支付”事件发生在零售商网站外部的环境中。通过 webhook，支付网关将调用零售商的注册 API，以便在支付数据可用时立即提供。然后零售商的服务器接受这些数据，使其能够更新其数据库和面向用户的屏幕。

营销平台 MailChimp 依赖 webhook 来订阅和取消订阅电子邮件列表，以及更改用户配置文件。SendGrid 提供 webhook 用于在事务性电子邮件已送达、打开或无意中未送达收件人时通知用户。

Stripe 通过 Webhook 提供收费成功或失败的通知。

Github 使用 webhook 处理与存储库相关的事件。包括代码推送、创建存储库和删除存储库在内的操作都依赖于 webhook，它们还配置了相关的持续集成/持续交付 (CI/CD) 流程。

 

作为应用程序提供者，您将回调 API 注册到将通知您事件发生的外部服务器。每当触发事件发生时，相关的 webhook 就会从外部系统收集数据，并通过您指定的 URL 以 HTTP POST 请求的形式将其发送到您的应用程序。

Webhook 封装了两个或多个应用程序之间的实时通信通道。Webhook 是高度可定制的，可以定制以满足各种业务需求。

 

请注意传统 API 和 webhook 之间的重要区别：

API 调用基于请求的输出机制工作，而 webhook 工作基于事件的输出机制。换句话说，在 API 依赖于用户输入的情况下，webhook 是从应用程序到服务器的自动调用。

 

实现 webhook 的过程如下：

• 在您的服务器上创建一个可以接受和处理 POST 请求的 URL。

• 将此 URL 提供给 Webhook 提供程序，然后 Webhook 提供程序发送 POST 请求并执行相关操作，即向指定 URL 发出 POST 请求以更新任何更改。

• 您的服务器处理此请求并将 POST 请求发送回 webhook 提供程序，以通知他们请求的操作已完成（或未完成，视情况而定）。

 

在大规模使用 webhook 时，如果您的系统由于某种原因出现故障，webhook 将无法将事件信息传递到您的系统。为了克服这个问题，您可以使用事件消息队列，例如开源 RabbitMQ 或 Amazon 的简单队列服务 (SQS)。两者都是专门为这种类型的用例设计的。实施后，在提供者端触发的任何事件都将存储在事件消息队列中。反过来，队列将尝试将事件的详细信息发送到您的应用程序。如果您的系统处于活动状态，它们会将“成功”消息返回到事件消息队列，然后删除相关事件。如果您的系统出现故障，队列会存储事件，以便在您的系统再次启动时重新发送。您可以配置队列的超时和重试机制如何工作。这种方法可确保在您的系统出现故障时不会丢失 webhook 事件。

 

 

4、事件驱动的 API。

 

事件驱动是一种架构设计模式，它定义了系统如何处理数据。它只是说明系统应该在事件发生时对其做出响应/反应。

 

Streaming、Pub/Sub 和 Push 都是可以通过事件驱动架构交付的消息传递模式。因此，它们都可以归入事件驱动 API 的范畴。

 

与请求数据的传统请求/响应 API 不同，事件驱动 API 将数据从生产者推送到消费者。

 

事件驱动世界中的一个事件会触发一系列事件，这些事件必须在下游进行处理，并延伸到整个数据供应链。该供应链中的所有组件都是反应式的，可以快速响应事件并执行后续处理。

 

该数据供应链的时限性、反应性导致工程和基础设施复杂性增加。与遵循请求/响应模型的 REST API 相比，复杂性被倒置并置于 API 生产者而不是 API 消费者身上。

 

 

 

框架：

 

Feathers 是一个轻量级的 Web 框架，用于使用 JS 或 TypeScript 创建实时应用程序和 REST API，

Feathers 可以与任何后端技术交互，支持十几个数据库并与任何前端技术（如 React、VueJS、Angular、React Native、Android 或 iOS）一起使用。

在几分钟内构建原型，在几天内构建生产就绪的应用程序。