Whats new in AsyncAPI v3
summary
AsyncAPI v3 replaces the confusing publish/subscribe flip by splitting operations out from channels so channels only define addresses and messages, adds keyed message definitions with reusable IDs, and formalizes four request/reply patterns including request/reply via replyTo header and same-channel replies. Servers split into protocol/host/path, security scopes move into components, traits now merge instead of overwrite, parameters become string-encoded, and a CLI converter and migration guide exist to automate most V2→V3 migrations with some edge cases needing manual fixes.
AI-written summary · about
chapters (17)
- 0:00AsyncAPI v3 intro
- 0:47Publish/subscribe confusion in v2
- 1:49Redefining operations
- 2:56Channels vs operations
- 4:24Request-reply in v3
- 9:42Multi-schema format objects
- 11:08Duplicate properties in traits
- 12:13Simpler server definitions
- 13:39Explicit references
- 15:50General questions about AsyncAPI
- 16:41Migration v2 to v3
- 18:27Channel reuse
- 21:20Design patterns
- 22:25Metadata changes
- 23:11Optional channels
- 24:17Parameter encoding
- 26:02Summary
related talks
26mNext Generation of AsyncAPI
30mAsyncAPI v3: Streamlining Event-Driven API Design
03mWhy AsyncAPI Is Essential for Modern Event-Driven Architectures
52mContract-Driven Development for Event-Driven Architecture.
27mAsyncAPI & The future of API specs
31mSpecify Your Asynchronous APIs with AsyncAPI
01h 03mOpenAPI and AsyncAPI, when to use which and why
39mIntroduction to AsyncAPI for Apache Kafka