You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now a few things are unclear that should be added to the documentation (explanation) or specification:
Why is a leading dot not allowed for topics (clarify doc) -> I know its bad practise but possible for mqtt
Why is it allowed for a base topics (possibly wrong?)
What about trailing dots? Are those allowed? (clarify doc)
Why are dots used? I saw that the docgen can replace dots with slashes. The first time I saw asyncapi I was wondering why dots are used and if I can use slashes instead. It should be more clear why dots are required and that they can be replaced by the docgen. Or 2nd option: Make dots a valid topic separator for mqtt
Just for my interest: Are dots used in other protocols? I've only seen slashes so far
Wouldnt it make sense to also add variable topics to the base topic? For example if you have a user specific API where you must call company/users/{userid}/{commands} or company/device/{serialnumber}/{commands}. That is a valid usecase I need.
The text was updated successfully, but these errors were encountered:
This is definitely a bug in the spec. Any string can be a topic.
It's true that it would be nice to have a baseTopic with variables.
The dots were used because I started this project for AMQP (RabbitMQ). But, as I said, you should be able to use any string you want. AsyncAPI should not need to make differentiation between topic part and topic separator. That's something the tooling should take care of.
The base topic are defined as strings:
https://github.com/asyncapi/asyncapi#baseTopicString
Normal topics are not allowed to start with a dot:
https://github.com/asyncapi/asyncapi#topicsObject
Now a few things are unclear that should be added to the documentation (explanation) or specification:
company/users/{userid}/{commands}
orcompany/device/{serialnumber}/{commands}
. That is a valid usecase I need.The text was updated successfully, but these errors were encountered: