Coming from OpenAPI

Notice

This article is about version 2.0.0-rc1 of the specification. Please note that documentation and tooling support are minimum or inexistent yet. We’re working hard to update everything to version 2.0.0 as soon as possible. Thanks for your patience.

If you’re coming from OpenAPI, you must know that AsyncAPI started as an adaptation of the OpenAPI specification. We wanted to have as much compatibility as possible between the two so users could reuse parts in both.

You’ll find lots of similarities between OpenAPI and AsyncAPI. Just bear in mind that, in the world of event-driven architectures, we have more than one protocol and therefore some things are different. Check out the following comparison chart, inspired by Darrel Miller’s blog post:

OpenAPI — AsyncAPI comparison

OpenAPI 3.0

Info
Hosts
Security
Paths
Path Item
Summary and description
Operation (GET, PUT, POST, etc.)
Request
Responses
Tags
External Docs
Components
Definitions
Responses
Parameters
Response Headers
Security Definitions
Callbacks
Links

AsyncAPI 2.0

Info
Servers (hosts + security)
Channel
Channel Item
Operation (Publish and Subscribe)
Summary, description, tags, etc.
Message
Headers
Payload
Id (application identifier)
Tags
External Docs
Components
Schemas
Messages
Security Schemes
Parameters
Correlation Ids
Traits

Aside from structural differences you must know that:

  1. In OpenAPI, the meaning of the operation verbs must be seen from a client perspective. E.g., the client can GET, POST, DELETE, etc. to these paths. However, in AsyncAPI the meaning of the verbs “publish” and “subscribe” must be seen from the application perspective. E.g., your application will publish and/or subscribe to these channels.
  2. OpenAPI schemas and AsyncAPI schemas are the same.
  3. Message payload in AsyncAPI can be any value, not just an AsyncAPI/OpenAPI schema. For instance, it can be an Avro schema or a Protobuf message.
  4. AsyncAPI server object is almost identical to its OpenAPI counterpart with the exception that scheme has been renamed to protocol and AsyncAPI introduces a new property called protocolVersion.
  5. OpenAPI path parameters and AsyncAPI channel parameters are a bit different since AsyncAPI doesn’t have the notion of “query” and “cookie”, and header parameters can be defined in the message object. Therefore, AsyncAPI channel parameters are the equivalent of OpenAPI path parameters.

Conclusion #︎

As we have seen above, OpenAPI and AsyncAPI are very similar. In a real world environment, systems don’t have just REST APIs or events but a mix of both. Most of the times, the information flowing in the events are very similar to the one the REST APIs have to handle in requests and responses, thus being able to reuse schemas is a huge win.

Enough speaking, let’s get our hands dirty with some examples. Learn how to create an AsyncAPI document defining a “Hello world” application.