5. Request/Response Semantics

CoAP operates under a request/response model similar to HTTP: a CoAP endpoint in the "client" role sends one or more CoAP requests to a "server", which services the requests by sending CoAP responses. Unlike HTTP, requests and responses are not sent over a previously established connection, but are exchanged asynchronously via CoAP messages.

5.1. Requests

A CoAP request consists of the method to be applied to the resource, the identifier of the resource, a payload and Internet media type (if any), and optional metadata about the request.

5.2. Responses

After receiving and interpreting a request, a server responds with a CoAP response that is matched to the request by a token generated by the client (Section 5.3).

5.2.1. Piggybacked

In the most basic case, the response is directly carried in the acknowledgement message that acknowledges the request (this requires that the request was carried in a Confirmable message). This is called a "Piggybacked Response".

5.2.2. Separate

It may not always be possible to return a Piggybacked Response. For example, a server might need longer time to obtain the representation of the requested resource than it can wait without risking the client repeatedly retransmitting the request message. The response to a request carried in a Non-confirmable message is always sent separately.

5.2.3. Non-confirmable

If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) to a Confirmable request, or a Confirmable response to a Non-confirmable request.

5.3. Request/Response Matching

Regardless of how a response is sent, it is matched to the request by the token included by the client in the request, along with additional address information of the corresponding endpoint.

5.3.1. Token

The token is used to match a response to a request. The token value is a sequence of 0 to 8 bytes. Every request carries a token generated by the client, which the server MUST echo (without modification) in any resulting response.

5.3.2. Request/Response Matching Rules

The exact rules for matching a response to a request are specified in the full RFC 7252 document.

5.4. Options

Both requests and responses may include a list of one or more options. For example, the URI in a request is transported in several options, and metadata that in HTTP would be carried in HTTP headers is supplied as options as well.

5.4.1. Critical/Elective

Options fall into one of two classes: "Critical" or "Elective". The difference between these is how an endpoint reacts to an option it does not recognize.

5.4.2. Proxy Unsafe or Safe-to-Forward

In addition to being marked as critical or elective, options are also classified based on how a proxy is to handle an option it does not recognize.

5.4.3. Length

Option values are defined to have a specific length, often in the form of an upper and lower bound.

5.4.4. Default Values

An option may be defined to have a default value.

5.4.5. Repeatable Options

The definition of some options specifies that those options are repeatable.

5.4.6. Option Numbers

Options are identified by an option number, which also provides some additional semantic information.

For complete details on request/response semantics, option definitions, and method codes, please refer to the official RFC 7252 document.