CoAP (Constrained Application Protocol) is a lightweight request/response protocol designed for use on resource-constrained nodes and lossy networks, such as low-power microcontrollers communicating over IEEE 802.15.4, LoWPAN, or other constrained links. It mirrors the REST model of HTTP but runs over UDP, keeping code and message size small enough for devices with kilobytes of RAM and flash, though actual footprint depends on the stack, features, and security options enabled.
In practice
CoAP is defined in RFC 7252 and is a natural fit for IoT sensor nodes, actuators, and gateways that need a standardized application-layer protocol without the overhead of TCP/HTTP. Its binary base header is only 4 bytes (though real on-wire overhead grows with options, tokens, and security), and messages can fit inside a single IEEE 802.15.4 frame (127-byte maximum payload), avoiding fragmentation on many common radio links. Typical targets include Cortex-M0/M0+ class devices (such as the nRF51 series, STM32L0, or Silicon Labs EFR32) running a minimal IP stack like lwIP or uIP, though CoAP stacks exist for even smaller 8/16-bit parts.
CoAP maps directly to REST verbs: GET, POST, PUT, and DELETE operate on URIs, and responses carry familiar status codes modeled after HTTP. This makes it straightforward to bridge CoAP traffic to an HTTP back-end through a proxy or gateway, which is a common architecture in constrained IoT deployments. CoAP also defines an observe extension (RFC 7641) that lets a client subscribe to resource updates, useful for streaming sensor data without polling.
Reliability is handled at the CoAP layer rather than the transport layer. Messages marked Confirmable (CON) require an ACK; messages marked Non-confirmable (NON) are fire-and-forget. This lets the application choose the right trade-off between reliability and power consumption on a per-message basis, which matters on duty-cycled radio nodes where retransmissions cost battery life. Be aware that CoAP's built-in retransmission logic is intentionally simple and has limitations when operating over high-loss or heavily reordered paths.
A practical concern when integrating CoAP into embedded firmware is that even lightweight stacks (libcoap, microcoap, Contiki's er-rest-engine, Zephyr's built-in CoAP module) have varying levels of support for optional features like blockwise transfer (RFC 7959), DTLS security (RFC 7252 Section 9), and the observe extension. Evaluate which features your deployment actually needs before selecting a stack, since DTLS in particular adds significant code size and requires a source of entropy. The blog post "Designing Communication Protocols, Practical Aspects" covers broader trade-offs when choosing and implementing constrained protocols that apply directly to CoAP integration decisions.
Frequently asked
Why use CoAP instead of MQTT on a constrained device?
CoAP and
MQTT serve different communication patterns. CoAP follows a request/response (REST) model and runs over
UDP, making it stateless and well-suited for resource discovery and on-demand reads. MQTT follows a publish/subscribe model over TCP, which suits event-driven streaming data but requires maintaining a persistent TCP connection, adding state and memory overhead. On very constrained nodes where maintaining a TCP connection is expensive, CoAP over UDP can be the better fit. Many designs use both: CoAP for device management and configuration, MQTT for telemetry pipelines.
How does CoAP handle reliability if it runs over UDP?
CoAP implements its own lightweight reliability mechanism. Confirmable (CON) messages must be acknowledged by the receiver; if no
ACK arrives within a timeout, the sender retransmits with exponential backoff up to a configurable maximum (default 4 retransmissions per RFC 7252). Non-confirmable (NON) messages carry no such guarantee. Message IDs and tokens are used to deduplicate retransmissions and match responses to requests. This is intentionally simpler than TCP and is appropriate for short, infrequent exchanges on lossy links, but it does not provide ordered delivery or congestion control.
Can CoAP be secured?
Yes. RFC 7252 specifies the use of DTLS (Datagram
TLS) as a security mechanism for CoAP, providing authentication, integrity, and confidentiality. DTLS adds significant code size and requires a CSPRNG for key material, which can be a problem on very small MCUs. For devices where DTLS is too costly, some deployments use CoAP inside a VPN tunnel or rely on network-layer security (e.g., 6LoWPAN with link-layer encryption). Object Security for Constrained RESTful Environments (OSCORE, RFC 8613) is a newer alternative that provides end-to-end security at the CoAP message level without requiring DTLS, and is increasingly considered alongside DTLS for constrained deployments.
What is blockwise transfer and when do I need it?
Blockwise transfer (RFC 7959) allows large payloads to be split across multiple CoAP messages, each fitting within the network's MTU. It is needed whenever a response or request body exceeds what a single
UDP datagram can carry without IP fragmentation, which on IEEE 802.15.4 links can be as little than 60-80 bytes of CoAP payload after headers. Common use cases include firmware-over-the-air (FOTA) transfers and reading large configuration blocks. Not all CoAP stacks implement blockwise transfer, so verify support if you need it.
How does CoAP resource discovery work?
CoAP defines a standard resource discovery mechanism via a well-known URI: a GET to coap://[device]/.well-known/core returns a CoRE Link Format (RFC 6690) payload listing the URIs and attributes of all resources the device exposes. This allows a gateway or management server to enumerate device capabilities without prior knowledge. On memory-constrained devices, generating this response dynamically can be expensive; some implementations store a static link-format string in
flash instead.
Differentiators vs similar concepts
CoAP is frequently compared to
MQTT. The key distinction is the communication model: CoAP is request/response (REST over
UDP), while MQTT is publish/subscribe over TCP via a broker. CoAP is also compared to HTTP: both are RESTful and share status code conventions, but HTTP runs over TCP and has a text-based header format that is far too large for constrained nodes. CoAP's binary 4-byte header and UDP transport make it orders of magnitude leaner than HTTP for small payloads on lossy links.
