Next Generation of AsyncAPI
summary
Proposal replaces publish/subscribe verbs with send/receive keywords so a service that processes a "userSignedUp" message is defined as receiving from that channel, not as others publishing to it. Channels become reusable via channel ID and address or by detaching operations to a root operations object. Schemas move schemaFormat into components so Avro/Protobuf/XSD payloads can be referenced. Request/response covers predefined, per-reply and dynamic reply topics (ping/pong example). Tooling is protected by an intent API that exposes stable calls.
AI-written summary · about
chapters (9)
- 0:00Start
- 5:03The Problem
- 6:15Proposed Solution
- 6:41Send/receive
- 11:45Schemas and formats
- 15:01Request and response pattern
- 19:03References and message payloads
- 22:00Intent API
- 24:50Changes
related talks
26mWhats new in AsyncAPI v3
29mMulti-Protocol APIs: Designing a Unified Interface for EDA
03mWhy AsyncAPI Is Essential for Modern Event-Driven Architectures
01h 03mOpenAPI and AsyncAPI, when to use which and why
27mAsyncAPI & The future of API specs
31mSpecify Your Asynchronous APIs with AsyncAPI
31mAsyncAPI is here to stay
39mIntroduction to AsyncAPI for Apache Kafka