Coming from OpenAPI

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, you have more than one protocol and therefore some things are different. Check out the following comparison chart, inspired by Darrel Miller's blog post:

Aside from structural differences you must know that:

1. AsyncAPI is compatible with OpenAPI schemas.
2. Message payload in AsyncAPI can be any value, not just an AsyncAPI/OpenAPI schema. For instance, it could be an Avro schema.
3. 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.
4. 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 you 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 time, the information flowing in the events is 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 your hands dirty with some examples. Learn how to create an AsyncAPI document defining a "Hello world" application.