10 ms·
The idea itself is sound, having an agreed specification allows others to build tools around this specification. (i.e. auto-generation, integration). In theory,
by makstaks 6y ago
The idea itself is sound, having an agreed specification allows others to build tools around this specification. (i.e. auto-generation, integration). In theory, this makes development easier. OpenAPI achieved this and is now widely used in various tools including Amazon API Gateway.
The types of diagrams you listed above are great for describing software in useful ways, but none of them are rigid enough to spec out an async API.
I still need to review this spec to fully understand it, so I'm not promoting AsyncAPI. I like the motivation behind it.
edit: typo
- MuffinFlavored 6y agoI don't quite get it. Why can't I just enforce schema validation in my pub/sub handlers? I see the YAML example completed here: https://www.asyncapi.com/docs/getting-started/servers/ https://www.asyncapi.com/docs/getting-started/servers/ asyncapi: 2.0.0 info: title: Hello world application version: '0.1.0' servers: production: url: broker.mycompany.com protocol: amqp description: This is "My Company" broker. channels: hello: publish: message: payload: type: string pattern: '^hello .+$' This looks like a thin wrapper around sending a message to a message queue. What's the gain? Where do you define what to do as a subscriber?
- derberg 6y agoyou have 2 operations in the spec, publish and subscribe. above example already tells you what to do as a subscriber, as the document you shared describes an application that publishes a message