上一篇文章中我们讲到了 OpenAPI 和 GraphQL 基于场景的使用区别，在这篇文章中我们继续分析AsyncAPI 和 OpenAPI 的使用场景及二者的异同。 OpenAPI和AsyncAPI是现代Web开发世界中广泛使用的两种流行的API规范。这两个API虽然具有一些相似之处，但是它们基于的特定使用情况有很大的区别。
在日常的开发过程中、开发、架构的角色经常会使用Restful API 和异步编程的范式， 基于Web 的开发模型的常见范式是发送请求并且等待请求响应，这种场景几乎占用了开发的大部分， 但是在日常开发过程中还存在一个场景， 这种范式的工作模式是只需要发送请求通知，不需要响应， 即 ”Fire-and-Forget“ 范式、这种范式提供了一种松耦合的集成解决方案，这种范式在很多场景下都存在， 比如： 企业级集成场景、 基于事件的架构（EDA）中。
AsyncAPI是一种基于EDA架构的API规范，旨在帮助开发人员建立对应架构下以规范为中心的API 开发模式和标准。其定义了一个协议，用于使用消息代理或事件驱动架构建立客户端和服务器之间的连接。与OpenAPI不同，AsyncAPI旨在与REST API和基于消息的API一起使用, 包括各种消息中间协议： WebSockts、HTTP、Kafka、MQTT等。
与OpenAPI 对于同步接口的规范和标准类似， AsyncAPI 提供了一种解决异步开发场景下的规范和标准， 其提供了规范的标准、验证、代码生成等能力， 从而为代码的编写提供了一致的标准和要求。
接下来我们通过一些场景实例来看下如何使用AsyncAPI 规范来完成异步接口的标准化及使用。
异步API在处理实时API时特别有用。实时API要求服务器向客户端发送持续更新，并且服务器必须以无状态方式运行。异步API通过使用基于消息的系统以确保实时信息共享，在构建实时API时提供了简化的方法。
以下是使用WebSockets的实时API的AsyncAPI规范示例：
在此示例中，AsyncAPI规范定义了一个WebSockets API，提供实时天气更新。
使用AsyncAPI可以实现另一种常见场景 - 事件驱动（EDA)架构。在这种情况下，消息在不同的服务之间交换以触发事件，可以在服务之间传递并根据需要进行处理，从而消除了需要进行更复杂的编排的需求。下面的示例中， AsyncAPI 规范定了一个 Hello world 应用，从基于amqp的消息中间件hello channel 中订阅消息。
异步API提供了一种更简化的服务之间通信方法，这极大地简化了基于微服务的应用程序的开发和部署，帮助消除瓶颈并在多个服务之间减少复杂性。
OpenAPI，前身 Swagger，是一种广泛采用的API技术，提供了一种标准化的API定义、构建和文档化的方法。它是一种用于描述RESTful API和Web服务的规范。OpenAPI具有语言无关性，并受到广泛支持的工具和技术的支持，这可以帮助开发人员更有效地构建和部署API，上一篇文章中我们已经基于场景介绍了 OpenAPI 这里不再赘述。
OpenAPI 和 AsyncAPI 规范比较图，来源Coming from OpenAPI | AsyncAPI Initiative for event-driven APIs:
综上，我们可以看到OpenAPI 和 AsyncAPI 是在不同场景下理念相同相互互补的API 规范，在实际环境中，系统不仅仅只有REST API或事件，而是两者混合存在。
大多数情况下，事件中传递的信息非常类似于REST API在请求和响应中处理的信息。因此，能够重用模式是一个巨大的优势, 两者都可以通过文档规范定义各自场景下的API ，自动生成代码，从而完成整个架构的规范和标准约束。
OpenAPI和AsyncAPI都是构建和部署API的出色工具，但它们是为不同的场景而设计的。 OpenAPI主要用于CRUD API操作和标准API定义，而AsyncAPI是用于服务或设备之间的事件驱动通信的实时通信。
