Message used for publishing might not be the same one received when subscribing

[fmvilas]

Even though I discourage to use different messages for the publish operation and the subscribe operation, it's something people are doing so we have to support it. Example:

https://ubidots.com/docs/api/mqtt.html#subscribe-to-a-variable

In this image, we can see how id is part of the message but it's only there when subscribing.

[MikeRalphson]

Similar to OpenAPI's readOnly / writeOnly properties?

[fmvilas]

Yes, that could solve this particular case, but speaking to some IoT providers they told me that when you subscribe to a topic you might receive a totally different message than the one you published in the same topic.

So I would say it should support both, readOnly/writeOnly and a totally different message for each operation.

Thanks Mike!

[philsturgeon]

Curious about how this is happening. Are there processes intercepting the events and manipulating them somehow?

[fmvilas]

@philsturgeon yes, that's what I've seen in some IoT applications. Not definitely a good practice in my opinion. But that's my personal opinion :)

[NicoHood]

I'd call that a bad design. This is something you should never do in mqtt. Publish and subscribe at the same topic, even with the same data.

And in the example above the id field can be marked optional. There you have your two options. And additionally you can specify both a subscriber and a publisher to the same topic, so where is the problem?

I possibly misunderstood something or the issue might be outdated.

[fmvilas]

I understand your point @NicoHood, but AsyncAPI is not only for MQTT and not only for broker architectures. The spec should not enforce any architecture decision.