Application Layer Protocols MQTT, HTTP, and CoAP

IoT Protocols: The Definitive Engineering Guide to Choosing the Right One

I've seen a startup spend three months integrating LoRaWAN into a product for a smart building application only to discover that the 10-second duty cycle limit on the protocol made their 1-second alert response requirement impossible. Protocol choice is architecture. Get it wrong early and you'll pay for it for the life of the product.

Start With Use Case, Not Protocol

The protocol conversation usually starts wrong: "We want to use MQTT" or "Let's go with LoRa" as if the protocol is a preference, like choosing a favorite color. Protocols are engineering constraints with specific trade-offs. The right question is: what is your data rate, range, power, latency, and infrastructure requirements? The protocol that satisfies all of them is the right choice.

Let me walk through the major protocols with the engineering lens they deserve, starting at the top of the stack: the application layer.

Application Layer Protocols: How Data Is Formatted and Routed

MQTT: The Default for Good Reason

MQTT was designed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Eurotech) for oil pipeline monitoring via satellite link. The design constraints were: unreliable network (satellite), constrained bandwidth, constrained device (SCADA terminal), and the requirement that disconnected devices receive messages they missed. The protocol that emerged from those constraints is perfectly suited for IoT, 25+ years later.

The publishing-subscribe model is the key innovation. Devices don't communicate directly with each other or with applications, everything goes through a broker. This decoupling means you can add new subscribers (dashboards, analytics pipelines, automation systems) without touching the device firmware. Add a new analytics subscriber to your fleet's topic tree and suddenly you have data visibility you didn't have before, without a firmware update.

QoS 0 sends once and hopes for the best, use for telemetry you can afford to lose ("at most once"). QoS 1 guarantees delivery but allows duplicates use for alarms and state changes where "at least once" is acceptable. QoS 2 guarantees exactly-once delivery the overhead is significant (four-way handshake), so only use it where duplicates cause real problems (billing, irreversible commands).

Last Will and Testament (LWT) is one of MQTT's most useful features and it's consistently underused. When you connect, you specify a "will" message, a topic and payload the broker publishes if your device disconnects ungracefully. This gives you automatic offline detection without any server-side logic.

HTTP/REST, Universal but Heavyweight

HTTP is the language of the web, and many IoT devices use it. The advantages: every platform speaks HTTP, debugging is easy (Postman, curl), and integration with web services is trivial. The disadvantages for IoT: request-response model requires polling for commands (wasteful for battery devices), headers add 500+ bytes of overhead per request (vs MQTT's 2-byte header), and there's no native push from server to device without Web Sockets.

HTTP is appropriate for: devices that only upload data (no commands needed), low-frequency uploads (once per minute or less), integration with existing web APIs, and scenarios where the device has mains power and bandwidth is cheap. HTTP is inappropriate for: battery devices, high-frequency data, bidirectional real-time communication.

CoAP: HTTP's Constrained Cousin

CoAP (Constrained Application Protocol) takes the REST mental model (URIs, GET/POST/PUT/DELETE) and puts it on UDP instead of TCP, with a 4-byte header instead of ~500 bytes. It adds "observe" mode where a server can push updates to a client without polling, elegant for resource-constrained devices. CoAP is used in LwM2M device management and some LPWAN applications, but it has less community and tooling than MQTT. Use it if you're already in an ecosystem that requires it; don't seek it out otherwise.