了解异步API

如果你主要使用过REST API，那么你可能对WebSocket和gRPC这样的异步API协议不太熟悉。异步API允许你流式传输数据、同时发送多个请求，并在服务之间智能地管理通信，而同步API则要求你每次需要数据时都发起一个新的请求。

虽然这两种类型的API都可以完成很多相同的事情，但你会发现某些用例更适合其中一种。让我们更深入地了解一下异步API与同步API之间的区别。

异步和同步API之间的区别

同步API通常使用HTTP或HTTPS作为传输协议，而HTTP是一个单向协议。客户端向服务器发送请求，然后服务器通过HTTP或HTTPS发送响应回客户端。

异步API则倾向于使用如HTTP/2这样的双向协议。当你使用双向协议时，客户端和服务器可以保持连接，根据需要发送和接收数据。可以这样理解：当你发起一个同步请求时，你是从服务器拉取数据，但你可以使用异步请求来要求服务器将最新数据推送给你。

当你向异步API发送请求时，你的应用程序可以在等待API服务器响应的同时继续处理用户的其他指令。这与同步API不同，在同步API中，应用程序会一直等待直到收到响应为止。

如果你请求的资源、服务或数据存储在请求时不可用，异步API可以使用回调（如Webhook）来通知你的应用程序资源何时准备就绪。这种方式提高了应用程序的响应性和效率，因为它不会阻塞其他操作的执行。

并非所有API架构都严格符合同步或异步的标签。例如，GraphQL可以被视为同步的，因为你通过HTTP发送查询，但它也支持使用WebSocket与其订阅服务器进行异步消息传递。你可以向GraphQL订阅服务器注册以接收异步更新，并且还有一个额外的好处，即你可以选择想要包含在响应中的确切字段。

微服务是异步API请求的一个绝佳用例。当你将应用程序的内部和外部服务配置为彼此异步通信时，这些服务可以在不同时间相互发送消息，这通常是通过使用消息代理来处理请求来实现的。

服务不必轮询以获取新信息，而是可以订阅它们关心的事件并接收推送更新。事件驱动架构依赖于服务之间这种发布-订阅模式的通信。以下图表展示了两个事件生产者使用发布-订阅模式与三个服务共享事件的示例：

HTTP/2还支持在单个连接上传输无限数量的消息，因此服务可以在交换数据时不必像HTTP那样每次请求都建立新的连接。

这使得它们更不容易达到浏览器的TCP连接限制。此外，它还允许应用程序在执行其他任务的同时在后台与API通信，这对于用户活动频繁的应用程序来说，可以提高性能和可扩展性。gRPC框架是内部服务的热门选择，因为它允许它们使用结构化数据负载高效地相互流式传输数据。

以下是一些可能使用异步API的应用程序示例：

在许多情况下，应用程序受益于同步和异步API的组合使用。虽然异步API可以提供诸如更快通信、更快响应时间和可靠扩展性等优点，但同步API也有其优势。

例如，如果你需要确保请求按特定顺序处理，那么同步API调用更为合适。同步API的设置也更为简单，因此它们仍然是直接请求-响应模式的理想选择。如果你还没有使用异步API，你可以在保留现有REST API功能的同时开始引入它们。这样，你可以根据自己的需求，灵活地选择使用哪种类型的API。