IoT messaging protocols are not interchangeable. Each was designed for specific constraints and optimises for different trade-offs between power consumption, bandwidth, reliability, and complexity. Choosing the wrong protocol early in an IoT project creates architectural debt that is expensive to correct once a fleet of devices is deployed.
MQTT (Message Queuing Telemetry Transport) is the most widely deployed IoT protocol and the right choice for the majority of enterprise IoT applications. It is a publish-subscribe protocol running over TCP, designed for unreliable networks and constrained devices. Its keep-alive mechanism maintains connections through intermittent network availability. Its Quality of Service levels — at most once, at least once, exactly once — allow you to choose the reliability-overhead trade-off appropriate for each message type. AWS IoT Core, Azure IoT Hub, and Google Cloud IoT Core all natively support MQTT. If you are building an industrial IoT application and do not have specific requirements that exclude MQTT, start here.
CoAP (Constrained Application Protocol) is designed for networks where MQTT's TCP overhead is too large — specifically for microcontroller-class devices with kilobytes of memory running on low-power wide-area networks. It is UDP-based, request-response (like HTTP rather than pub/sub), and uses binary encoding for minimal overhead. LoRaWAN deployments for agricultural sensors and smart city applications commonly use CoAP.
AMQP (Advanced Message Queuing Protocol) is an enterprise messaging protocol that predates IoT — it is the protocol underlying RabbitMQ. Its rich routing capabilities and guaranteed delivery semantics make it appropriate for IoT-to-backend integration scenarios where messages must be routed to multiple consumers with complex rules. It is too heavyweight for device-side deployment but well-suited for broker-to-application integration.
HTTP/REST is widely used in IoT despite not being designed for it — its ubiquity means every language and platform can use it without a specialised library. Acceptable for devices with good network connectivity and moderate message rates, but significantly less efficient than MQTT for battery-powered or bandwidth-constrained devices.