
The new version of the AsyncAPI specification - 3.1.0 - is now available. It looks like we are out of the long break after v3 release.
This is a minor release, and it doesn't bring any breaking changes. You can switch to it by modifying the following value in your AsyncAPI file
asyncapi: '3.0.0'intoasyncapi: '3.1.0'without any issues.
New protocol bindings
The specification is now extended to support another custom protocol through the bindings feature:
ROS 2 (official docs), thanks to @gramss and @amparosancho.
For more details, check out ROS 2 binding definition.
Tooling support
The following official AsyncAPI tools are already updated to support the 3.1.0 version of the specification:
- JSON Schema that supports validation of AsyncAPI documents with ROS 2 binding is updated in this repository. Also @asyncapi/specs package has been updated on NPM to version 6.11.1.
- JavaScript Parser uses latest @asyncapi/specs package and can be used to parse and validate 3.1.0 documents. Upgrade to the latest version.
- JavaScript Converter uses latest @asyncapi/parser package and can be used to convert to 3.1.0 documents. Upgrade to the latest version. This conversion is just the version change in
asyncapifield. - AsyncAPI Studio is also updated so just go to https://studio.asyncapi.com/ and see you can already write 3.1.0 documents.
Thank you
Huge thanks to contributors of the new addition to the spec: Amparo Sancho Arellano and Florian Gramß.
Huge thanks to specification maintainers that supported the process: Fran Méndez, Dale Lane, Vladimír Gorej, and Lukasz Gornicki.
Huge thanks to maintainers that helped with smooth updates of core tooling: Maciej Urbańczyk, Ashish Padhy, Pavel Bodiachevskii, Fran Méndez.
And I (Lukasz Gornicki) was your release coordinator, and I just gave myself a round of applause.
Look ahead
We now regularly meet to work on the AsyncAPI specification, and anyone is welcome to join. Meetings are coordinated through this GitHub issue.
Next topics on the agenda:
- Documenting channels with late or out-of-sequence events: For folks with experience in streaming, frameworks like Apache Flink or Apache Spark, please look into this proposal to add the possibility of specifying expected event delivery latency to AsyncAPI contracts.
- Support AND logic for multiple security schemes: Currently, AsyncAPI allows you to specify a list of security mechanisms where only one must be satisfied. The idea is to also allow users to specify that multiple mechanisms must be satisfied.
- Discriminator support to be aligned with OAS3: Right now, the discriminator field in AsyncAPI is just a string, which is too limited. People end up using it in combination with const as a workaround. We should consider aligning with the OpenAPI Discriminator Object, but we also need to address the fact that the discriminator is and would be limited to the AsyncAPI Schema. We need a solution that works for people using other schema formats, like Avro or Protobuf, for example.
Photo by Chinapat Saegang on Unsplash