MQTT vs CoAP vs HTTP: Picking the Right IoT Protocol

The protocol layer of an IoT product is one of those decisions that looks generic until it is wrong, and then it cascades into firmware, infrastructure, and operational pain. Three protocols cover almost every real project. The trade-offs are clearer than the marketing makes them sound.

HTTP / HTTPS

HTTP is the right answer more often than IoT engineers admit. It is trivially understood by every cloud service, has a vast ecosystem of debugging tools, and works through every firewall and corporate proxy. For low-frequency telemetry — say, an hourly upload — HTTP’s overhead is irrelevant.

When HTTP is the right call:

• Devices that report infrequently (minutes to hours between messages).
• Mains-powered or large-battery devices where the keep-alive cost is irrelevant.
• Workflows that fit a request/response model — uploading a report, fetching configuration, calling a webhook.
• Teams whose cloud expertise is far stronger than their embedded expertise. HTTP keeps the cloud side simple.

The hidden cost: TLS handshake overhead per request. For chatty workloads this dominates, which is when MQTT starts to win.

MQTT

MQTT is the de facto standard for high-frequency, persistent IoT connections. The advantages are real:

• A single TLS handshake for the lifetime of the connection, with cheap pub/sub messages on top.
• A broker-mediated model that decouples publishers from subscribers — devices, services, dashboards all subscribe to topics they care about.
• QoS levels that let you choose between fire-and-forget, at-least-once, and exactly-once semantics.
• A small footprint that fits comfortably on resource-constrained devices.

When MQTT is the right call:

• Devices that report continuously or near it (seconds between messages).
• Many-to-many flows where multiple cloud consumers want the same telemetry.
• Battery-sensitive devices where TLS handshake cost matters.
• Architectures where bidirectional control is needed — sending commands back to devices.

The trade-offs:

• The broker is a stateful component. You operate it, scale it, and monitor it. Managed brokers (AWS IoT Core, EMQX Cloud, HiveMQ Cloud) help, but they are not free.
• QoS 1 and 2 require persistent state on both sides. Devices that drop and reconnect frequently need careful session-handling configuration.
• MQTT 5 is the version you want, not 3.1.1. The improvements (better error reporting, message expiry, shared subscriptions) are real.

CoAP

CoAP is the dark horse. It is HTTP’s semantics over UDP, designed specifically for constrained devices — small packets, no connection overhead, optional reliability layered on top.

When CoAP is the right call:

• Battery-critical devices that cannot afford a persistent connection.
• Constrained networks (LoRaWAN, NB-IoT) where every byte counts.
• Workloads where multicast and group communication matter — turning on every light in a building, for example.

The trade-offs:

• Smaller ecosystem. Cloud-side support is thinner; debugging tools are fewer.
• Operational expertise is harder to hire for.
• Many corporate networks block UDP traffic.
• The natural fit is hybrid: CoAP from device to gateway, MQTT or HTTP gateway-to-cloud.

How we choose in practice

A short decision tree:

1. Does the device report less than once per hour? → HTTP. Done.
2. Does the device need persistent bidirectional communication or report multiple times per minute? → MQTT.
3. Is the device on a constrained radio (LoRaWAN, NB-IoT) and is the upstream gateway already speaking MQTT or HTTP? → CoAP on the device side, translation at the gateway.
4. Is the device in a regulated domain that requires specific protocol guarantees? → Match what the regulator expects. Often that is HTTPS with a specific TLS profile.

Things that are not actually protocol decisions

Some debates that look like protocol choice are something else:

• “We should use WebSocket because it’s bidirectional.” WebSocket is a transport. Layer MQTT, CoAP, or your own protocol on top. The decision is what messages flow, not whether they ride on a socket.
• “We need exactly-once delivery.” You probably need idempotent processing on the cloud side. That is cheaper and more reliable than exactly-once delivery from the device.
• “The protocol must support millions of devices.” Every protocol can. The question is whether your broker, your network, and your wallet can.

Two practical patterns

These two architectures cover most IoT projects we ship.

The “every IoT product” pattern:

• Devices speak MQTT over TLS to a managed broker (AWS IoT Core, Azure IoT Hub, or self-hosted EMQX).
• The broker forwards messages into a stream processor and a time-series store.
• A REST API on top serves dashboards and admin tools.
• Devices upload large blobs (firmware, captured images, audio) over presigned HTTPS URLs to S3 or equivalent.

The “constrained IoT” pattern:

• Devices speak CoAP to a gateway on a LoRaWAN or NB-IoT network.
• The gateway translates to MQTT for cloud ingestion.
• Cloud architecture is identical to the first pattern.

Each is boring, well-trodden, and works.

If you are mid-protocol-decision, we are happy to look at your spec for an hour.