Is there anything wrong using HTTP POST and not MQTT?

[segdy]

I read the documentation but this topic is not really discussed.

I understand that MQTT is fairly powerful and allows bridges and stuff and potentially facilitates integration with other systems.

But this aside, I feel it just increases the complexity unnecessarily. Setting up the MQTT server, making sure the certificates renew etc, securing an additional service etc.

And whenever two services rely on each other to be running (without a reliable buffer in between) I feel a bit uncomfortable. In our case, the MQTT server has to be running. If for whatever reason it is killed or there is a gap in start time between MQTT server and ot-recorder, the data is just dropped, and there is not even a way to see this quickly and easily. So I'm afraid of silent data loss.

I don't really need to share my location with other people nor do I need other people's location, so MQTT bridging isn't really a thing for me. So I feel, just using HTTP POST would be much easier, simpler, more reliable.

Is there any disadvantage on this? E.g., in terms of security, reliability or performance? For example, would one drain the battery of the mobile device less?

[jpmens]

I don't think we've made any measurements in battery consumption HTTP vs MQTT, whereby the former is bound to consume a bit more due to protocol overhead, but that's likely negligeable in this case.

There's nothing wrong with using HTTP, and if it suits you better, go ahead. One thing though: the certificate renewal, etc. is just as much work for the one as for the other, but if you already have it set up for HTTP it is, indeed, easier.

[growse]

Agree with @jpmens but wanted to add a point you touched on about reliability and buffering.

The OT data flow is a pretty simple source (app)->sink (recorder), and like any system that wants to do this needs to be able to deal with anything along this pathway being faulty or unavailable. You're right that MQTT introduces another component between source and sink, to the extent where the app only now cares about the availability of MQTT - once a message has been delivered and acknowledged by the MQTT broker, the app assumes the message is no longer its responsibility. The issue that some people run into is that MQTT is essentially a buffer of size "1", so if the recorder is not alive to consume the published message when the app publishes a second message, the first one will effectively be lost.

An HTTP endpoint whose ability to receive and process messages is more closely coupled with the liveness of the recorder doesn't have this problem, because a recorder that is unavailable will cause the HTTP responses to be errors, therefore causing messages to be buffered in the app where there is a queue. Older messages can be held pending delivery whilst also logging newer messages as they're generated.

As ever, this is about trade-offs. More components increases complexity and failure scenarios. If you care about never dropping any messages (as some do), then a simple MQTT -> recorder topology may not suit your needs and HTTP might be better. If, however, you want to take advantage of some of the other MQTT features (communicating broker -> app, integration with other systems etc.) then, HTTP might not be the right choice.

There's no "right" answer. It's just about choosing the thing most appropriate and being aware of the drawbacks.

[jpmens]

Closing as answered