The IBM IoT Foundation allows devices to submit events to the IBM cloud for consumption and recording. There appears to be two primary mechanisms to achieve the transmission of events ... MQTT and REST (HTTP POST requests). Assuming that a project will have sensors with direct TCP connectivity to IBM cloud over the Internet, what might we consider as the potential distinctions between the two technologies? What factors would case us to choose MQTT or REST as the technology to use? Are there any substantial performance differences at the final mile at the IBM end that would say that one technology is preferred over another?
REST is a representational state transfer architectural style designed as a request/response model that communicates over HTTP. MQTT is a publish/subscribe model that runs over TCP/IP sockets or WebSockets. MQTT over WebSockets can be secured with SSL.
MQTT is used for data exchange between constrained devices and server applications. It keeps bandwidth requirements to an absolute minimum, handles unreliable networks, requires little implementation effort for developers, and is, therefore, ideal for machine-to-machine (M2M) communication.
The MQTT protocol is thus energy-efficient and easy to deploy for millions of devices. Connecting devices during unreliable networks: MQTT in IoT uses QoS levels to ensure guaranteed delivery of messages to receivers, even when connections between devices are unreliable.
They both run over TCP connections, and are both client-server in architecture, but MQTT allows messages to pass in both directions between clients and servers whereas HTTP servers only respond to requests from clients.
MQTT is designed to be a fast and lightweight messaging protocol, and is as a result, faster and more efficient at this than HTTP when used to do the equivalent. More efficient not only means less traffic data and more speed, but sometimes it can mean less electrical power as well. MQTT is particularly good where bandwidth is a concern.
MQTT does, however, need a client implementation (like Paho) which is possibly a rarer thing than an HTTP client implementation, which would be more ubiquitous and therefore more likely/easily available on any given device.
There are also TCP/IP port considerations, where some network hardware may require HTTP ports 80 or 443 (although IoTF supports MQTT and MQTTWS on port 443).
There may also be an ideological or philosophical reason for choosing HTTP instead of MQTT (or COAP for that matter), but usually, I would say the reasons for choosing HTTP instead of MQTT would be network related or client support related.
There is no official paper on the performance differences yet, but safe to say MQTT will be more efficient and faster given just about any messaging scenario (long lived connections or adhoc etc.)
I would summarize the considerations as:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With