Application Protocols

Application Protocols Roadmap

An IoT device does not just “send data.” It sends a message that another system must understand, store, route, secure, and sometimes act on immediately. Application protocols define that message behavior.

This book helps you choose and use the protocols that sit above TCP, UDP, IP, Wi-Fi, cellular, LoRaWAN, Ethernet, and other network links. The goal is practical: when a sensor reading leaves a device, you should know whether it belongs in a REST request, an MQTT topic, a CoAP resource, or an AMQP queue.

Why This Matters

In real IoT projects, protocol choices affect battery life, latency, reliability, cloud cost, debugging, and long-term maintainability. A poor choice can make a good device feel unreliable: messages arrive late, gateways drop offline devices, cloud services cannot scale, or field technicians cannot understand what the system is doing.

By the end of this book, you should be able to explain the trade-off behind each protocol choice, not just name the protocol.

Start Here

If you are new to application protocols, use this sequence:

  1. REST and HTTP first: learn the request-response model used by dashboards, cloud APIs, device management portals, and integrations.
  2. MQTT next: learn publish-subscribe messaging for telemetry, commands, retained state, and unreliable networks.
  3. CoAP after that: learn REST-style messaging for constrained devices and UDP-based systems.
  4. AMQP last: learn broker-side routing, queues, acknowledgments, and enterprise messaging patterns.
  5. Review chapters and labs: use the comparison, worked examples, and knowledge checks to decide which protocol fits a scenario.
Beginner rule of thumb

Use REST when one system asks another for something. Use MQTT when many devices continuously publish telemetry or receive commands. Use CoAP when constrained devices need REST-like behavior. Use AMQP when back-end services need durable queues and routing guarantees.

Protocol Decision Map

REST / HTTP

Best for: configuration, dashboards, cloud APIs, firmware metadata, reports, and integrations.

Mental model: a client asks a server for a resource or sends an update.

Start with: REST API Design

MQTT

Best for: telemetry streams, commands, device shadows, mobile links, and gateway-to-cloud messaging.

Mental model: devices publish to topics, subscribers receive matching messages.

Start with: MQTT Fundamentals

CoAP

Best for: constrained nodes, local control, UDP networks, and resource-oriented embedded systems.

Mental model: REST-like resources for small devices and low-overhead networks.

Start with: CoAP Overview

AMQP

Best for: enterprise back ends, reliable queues, work distribution, routing rules, and service-to-service messaging.

Mental model: exchanges route messages into queues for consumers to process safely.

Start with: AMQP Fundamentals

No-Hardware Decision Lab

Read each situation, choose a protocol, then open the answer. The point is not memorization; the point is learning which design constraint matters most.

Scenario A: A weather station sends temperature and humidity every 30 seconds over a weak cellular link. A cloud dashboard and alert service both need the same readings.

Recommended protocol: MQTT. The publish-subscribe model lets the device send once while multiple cloud consumers subscribe. MQTT also handles intermittent links better than repeated REST polling.

Scenario B: A mobile app changes one device setting, then immediately needs confirmation that the setting was accepted.

Recommended protocol: REST or MQTT command-response depending on the system. REST is easiest when the device is reachable through a cloud API. MQTT is better when the device is usually behind NAT or on a mobile network.

Scenario C: A battery-powered sensor on a constrained local network exposes a few readable resources, such as temperature and battery voltage.

Recommended protocol: CoAP. It keeps the resource-oriented model of REST while reducing overhead for constrained devices and UDP-based networks.

Scenario D: A factory back end must route machine events into different processing queues, retry failed work, and avoid losing critical messages.

Recommended protocol: AMQP. Exchanges, queues, acknowledgments, and dead-letter handling make it suitable for reliable service-to-service processing.

How To Study This Book

  • Read for decisions first: each protocol chapter should help you answer “when would I use this?” before implementation details.
  • Use comparisons actively: do not treat REST, MQTT, CoAP, and AMQP as interchangeable. They solve different communication problems.
  • Prefer interaction over copy-paste: when a chapter includes a simulator, selector, calculator, or quiz, change the inputs until the trade-off becomes obvious.
  • Keep code in context: code examples matter only after you understand the message pattern, reliability expectation, security boundary, and deployment environment.

Useful Entry Points

  • REST API Design: start here if you are building dashboards, device management APIs, or integrations.
  • MQTT Fundamentals: start here if you are sending telemetry or commands between devices, gateways, and cloud services.
  • CoAP Overview: start here if you work with constrained devices or REST-style local embedded communication.
  • AMQP Fundamentals: start here if your back end needs queues, routing, and delivery guarantees.
  • Protocol Comparison: use this when you need to justify a protocol choice.

Use the sidebar for the full chapter sequence, or use search when you already know the protocol or concept you need.