That avoids having to amend the original standard for each new variation. If you get enough variants (probably in the neighborhood of 2-4), then it makes sense to go back and supersede the original standard by breaking out the high-level layers each into their own standard that's designed for inclusion in other standards. That way, for instance, your async-Bluetooth standard doesn't have to refer to any document that gets bogged down in HTTP/1.1-specific messaging semantics. It's not worth re-factoring your standards stack the first time you reuse a standard, but you don't want some big spaghetti tangle of standards, either.
Why reinvent the wheel? What does this add to the current state of the art? I can't even find a "Related Work" section on their site.
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.
I see the YAML example completed here: https://www.asyncapi.com/docs/getting-started/servers/
title: Hello world application
description: This is "My Company" broker.
pattern: '^hello .+$'
Where do you define what to do as a subscriber?
above example already tells you what to do as a subscriber, as the document you shared describes an application that publishes a message
What would be really cool is if this could serve as a front-end to e.g. SPIN model checker ( https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/Promela )
This isn't just config-file YAML.
This is programming-language YAML. :/
I'm working on what can be pretty well reduced to an AST builder. I have nodes of certain types which come with a set of relevant properties as well as the set of types that you're allowed to nest. I'm looking for a markup language to express these schemas so that I can generate the UI components (given parent node X, generate a widget with a form that can be used to submit legal children) and perform validation (given AST tree coming from the client, validate it server-side before persisting it)
Currently using JSON schema but it's very verbose. Any ideas?
The project we are building on top of cuelang may be of interest: https://github.com/hofstadter-io/hof
How does this one look on mobile? https://docs.hofstadter.io
I just started that yesterday from the most recent docsy.
I ended up trashing it and going for something more fluent, which I think could easily generate AsyncAPI YAML. Maybe I'll add that to the list of issues on my little side project.
JSON-RPC is simple, transport agnostic, can support any transport like Websockets, HTTP, even PostMessage.
So, similar difference between a Dictionary and a Database.