2 CoAP Fundamentals

coap

2.1 Start With a Sleeping Sensor

Imagine a soil sensor that wakes for a few milliseconds, reports moisture, listens for a new sampling interval, and goes back to sleep. HTTP can describe the same resources, but its connection setup and verbose headers waste the radio time the device is trying to save.

CoAP starts from that everyday constraint. The protocol keeps the resource model familiar, then trims the exchange down to compact UDP messages, tokens, discovery records, and delivery choices that can be tested on a lossy link.

Overview: CoAP Makes Resources Cheap Enough for Constrained Nodes

The Constrained Application Protocol keeps the resource model that makes HTTP easy to reason about: a client sends a request to a URI, chooses a method such as GET or PUT, and receives a response code plus a representation. The difference is the operating environment. CoAP is built for small devices and constrained networks, so it runs over UDP and keeps the base message compact.

The practical value is not that CoAP imitates the web. The value is that it lets a sensor, actuator, or local gateway expose a small resource interface without carrying a full web stack on every exchange. A temperature sensor can expose /sensors/temp. A valve controller can accept a PUT to /actuators/valve. A commissioning tool can discover resources before it writes a control rule.

For example, a cold-room node might report /temp every minute with non-confirmable readings because the next sample replaces a lost one, while a maintenance tablet sends a confirmable PUT to /defrost because a missed command changes equipment behavior. Both exchanges use the same resource model, but the message type, retry expectation, and review evidence differ. That is the core CoAP habit: keep the API small, then choose reliability per consequence.

If you only need the intuition, remember this: use CoAP when a constrained node needs REST-like request and response behavior, UDP is acceptable, and the system can make reliability choices per message.

CoAP keeps the resource interface small while exposing message-type and header choices that control reliability and overhead.

Resource model

Devices expose named resources. Clients use URI paths, methods, response codes, and representations to read or change state.

Compact messages

The base message is small and binary. Options encode method, URI, content format, tokens, caching, and other metadata.

UDP transport

CoAP avoids connection setup, but the application must choose where it needs acknowledgments, retries, security, and duplicate handling.

Protocol fit

CoAP fits constrained request-response and local control. MQTT fits brokered telemetry streams. HTTP fits broad web and cloud integration.

Practitioner: Write the CoAP Exchange Record

A CoAP design should be reviewed as an exchange record, not just as a protocol name. The record names the resource, method, payload format, expected response, message type, security boundary, and the evidence that the exchange works under expected loss and latency.

This keeps design conversations concrete. A team can argue about whether a valve command should be confirmable, whether a temperature reading may be cached, whether a gateway may proxy the request, and whether the payload belongs in JSON, CBOR, SenML, or another representation.

Resource discovery makes the exchange record inspectable: available paths, resource types, and interfaces can be listed before clients depend on them.

Field

Example

Review Question

Evidence

Resource

/sensors/air/temp

Does the URI name one stable resource rather than an implementation detail?

Discovery output and client trace show the same path.

Method

GET, PUT, or POST

Is the method consistent with read, replace, or create/action semantics?

Response code and state change match the method.

Reliability

CON for commands, NON for disposable readings

Would a lost message create unsafe behavior or only stale telemetry?

Loss test shows acceptable retry, latency, or drop behavior.

Caching

Max-Age on readable resources

Can clients or proxies reuse a response without hiding important state changes?

Freshness test matches the published Max-Age value.

Practitioner Checklist

Name the resource path and make sure it maps to a device state, command endpoint, or collection that operators can explain.
Choose a method before choosing a payload. A wrong method is usually a contract problem, not a serialization problem.
Mark each request as confirmable or non-confirmable according to consequence, not habit.
Record how the client authenticates the server, how the server authorizes the operation, and whether a gateway or proxy terminates security.
Capture a packet trace or gateway log that shows request code, response code, token correlation, retransmission behavior, and payload format.

Under the Hood: Message Layer, Tokens, and Failure Boundaries

CoAP has two important layers of meaning. The request-response layer says what the client wants: a method, URI options, payload, and expected response. The messaging layer says how the datagram exchange behaves: confirmable, non-confirmable, acknowledgment, reset, message ID, and token.

The message ID helps detect duplicates at the message layer. The token correlates a response with the request that caused it, which matters when several requests are in flight. A confirmable message asks for an acknowledgment and may be retransmitted if no acknowledgment arrives. A non-confirmable message avoids that exchange when loss is acceptable or the next reading will replace the old one.

The compact CoAP message carries both application meaning and correlation fields needed for lightweight exchanges.

Separating request semantics from message behavior lets one protocol support both dependable commands and low-overhead telemetry reads.

Message ID

Used by endpoints to match acknowledgments and suppress duplicates at the message exchange boundary.

Token

Chosen by the client to correlate a response with the original request, especially when several requests are outstanding.

Options

Carry method, URI path, content format, caching, observe registration, block-wise transfer, and other structured metadata.

Failure boundary

UDP can lose, reorder, or duplicate datagrams. CoAP handles selected cases, but the application still defines acceptable consequences.

Common Boundary Decisions

Use confirmable messages for commands or configuration writes where silent loss would create wrong device state.
Use non-confirmable messages for frequent, replaceable readings where freshness matters more than delivery of every sample.
Use block-wise transfer for larger representations so one lost fragment does not force the whole payload to restart.
Use Observe when clients need change-driven updates from a resource, but document how notifications are rate-limited and cancelled.
Use DTLS or an equivalent deployment security plan when the exchange crosses an untrusted network.

2.2 Summary

CoAP is a constrained-device application protocol for resource-oriented request and response exchanges. It keeps familiar REST ideas such as resources, methods, response codes, and representations, but carries them in compact UDP messages with explicit reliability choices.

Use CoAP when a small device or local gateway needs a lightweight resource interface and the deployment can reason about message loss, duplicate handling, caching, discovery, security, and proxy behavior. Do not choose it only because it sounds smaller than HTTP. Choose it when the exchange record proves that its resource model and failure boundaries match the system.

Note

Key Takeaway

CoAP is the right default for constrained REST-style device exchanges only when the resource contract, reliability choice, security boundary, and runtime evidence are all explicit.