## 6 M2M Application Protocols
### HTTP and CoAP  
CoAP is a lightweight protocol that complies with the REST paradigm [54], and is designed for the use in constrained networks and nodes in M2M applications. In REST architectures, as in HTTP, clients perform operations on resources stored at a server by means of request and responses exchanges. There are four types of requests for the clients:  
* gets/retrieves the content of an existing resource;
* creates a new resource;
* changes/updates the content of an existing resource;
* deletes/removes an existing resource. An Uniform Resource Identifier (URI) is used to identify resources, as in HTTP. CoAP easily translates to HTTP for integration with the Web, while accomplishing specialized requirements such as multicast support, built-in resource discovery, block-wise transfer, observation, and simplicity for constrained environments. CoAP also supports asynchronous transaction support. Like in HTTP, the clients do not need to maintain state, _i.e_., clients can be stateless [54]. CoAP is conceptually separated into two sub layers: a messaging layer that provides asynchronous messaging services over datagram transport, and a request-response layer that provides handling and tracking of requests and responses exchanged between a client and service side application endpoints. The request-response layer provides direct support for web services. The CoAP request-response semantics are carried in CoAP messages, and a token is used to match responses to requestsindependently of the underlying messages. Every response message can be returned within an ACK message, that is, piggybacked. CoAP also supports asynchronous responses, for the cases when the service side knows that it will take long to answer a request. If a client knows at start that an asynchronous response is expected or tolerated, then it includes a Token Option in the message. If the service side knows it might need a longer time to fulfil a request from a client, then it might ask for the client to add a Token option again to that message. The messaging layer implements the publish-subscribe model. This part of the protocol extends the CoAP core protocol with a mechanism for a CoAP client to constantly observe a resource on another CoAP entity, thus termed CoAP observer model [61]. This mode requires that each M2M entity has a client and a server. To use the same terminology as in publish-subscribe, from now on a client is a subscriber and the observation is a subscription. The subscription is made with an extended GET message. With the subscription, each subscriber that has an observation relationship with the event is notified by the publisher where it made the subscription, see Figure 3. In this model, the publisher also acts as a broker. As long as subscribers send acknowledgements of notifications sent in Confirmable CoAP messages by the publisher, the subscriber remains on the list of observers. If the transmission of a notification times out after several attempts or the subscriber rejects a notification using an RST message, then the subscriber is removed from the list of observers. The observer model follows a best-effort approach for sending new representations to subscribers because, if the network is congested or the state changes more frequently than the network can handle, the publisher can skip notifications for any number of intermediate states. The observer model provides consistency between the actual resource state at the publisher and the state observed by each subscriber, thus keeping the architectural properties of REST. Resource discovery is performed by sending a Confirmable GET request to the resource \"well-known/core\" at the server. In order to make CoAP suitable for constrained devices (memory, processing, bandwidth, and energy consumption restrictions), the User Datagram Protocol (UDP) is the preferred transport protocol due to less protocol overheads than the Transmission Control Protocol (TCP), and CoAP's header can be reduced to 4 bytes.