## 2 Constrained Application Protocol
### Application Protocols for WSNs  
The HTTP/TCP stack is the standard solution used for building RESTful Web services. The implementations presented in [23, 24, 25, 26, 27, 28] are the first examples that proved the feasibility of applying the HTTP/TCP stack in constrained networks. However, these solutions are tailored for specific applications. As a consequence, only the TCP or IP capabilities that are needed by the application are implemented. Many of these implementations miss of IP fragmentation, retransmission or congestion control mechanisms.  
The authors of [29] have analyzed the resource costs of building Web services for WSNs following the HTTP/TCP paradigm. The authors suggest design options that could lower the resource consumption. The use of persistent TCP connections as well as the avoidance of delayed acknowledgments has been proposed. The use of HTTP 1.0 is also suggested for its better integration with the persistent TCP connections. In our paper we evaluated an HTTP embedded Web Server adopting these design principles.  
The latest research trends have considered the study of alternative solutions to the HTTP/TCP stack. Although feasible, the application of this stack in constrained networks presents several issues regarding its overhead and impact on bandwidth. In fact, the HTTP protocol header is too chatty for the limited space available in 6 LoWPAN frames. Furthermore, as reported in [30], HTTP has evolved into a complex protocol involving optional headers and a number of features that increase the complexity of its implementation in constrained devices. Finally, the TCP protocol would have a poor effect on the available bandwidth of WSNs. However, a HTTP/TCP solution would ensure interoperability between different networks without the need for any intermediate translation proxy. The adoption of a lightweight binary protocol that could be easily mapped to HTTP would meet both requirements.  
An early proposal for a protocol to interact with sensors using RESTful Web services is presented in [5]. This protocol is called TinyREST. The TinyREST commands were composed by combining the request method with the URI of the sensor resource. These request methods were limited to the POST, GET and SUBSCRIBE requests of HTTP. Instead of using IP, TinyREST uses the networking tools provided by the TinyOS active message stack. The messages were transmitted as plain ASCII and generated an overhead of 29 bytes. The use of TinyREST was intended only for communications inside the WSN. The interaction with external Web services was performed through a gateway responsible for translating the HTTP messages into TinyREST messages.  
A proposal for a binary version of HTTP, which is called Embedded Binary HTTP (EBHITTP), has been defined in [31]. An application of EBHTTP for building RESTful Web Services has been considered in [32]. EBHTTP is a binary-formatted and stateless encoding of the standard HTTP protocol. Its use is intended for resource constrained WSNs. The design of this protocol focuses in reducing the overhead of HTTP while maintaining the same HTTP semantics and communication paradigm. EBHTTP uses the UDP protocol instead of TCP. The first proposal of the CoRE working group, called Chopan [33], follows the EBHTTP idea of compressing HTTP messages into a binary format. As EBHTTP, Chopan uses UDP as transport protocol. The proposal also included the presence of transparent caching and gateways for translating Chopan into HTTP. The weaknesses of the Chopan and EBHTTP proposals consist of the lack of reliability and in the processing power required to encode the HTTP protocol. In fact, although the processing required to encode the protocol would be less than that required by a direct use of HTTP, it would be still expensive due to the limited resource of a sensor. Furthermore, although they are bound on UDP, they do not provide any reliability mechanism. As a result of these limitations, attention has been shifted to the definition of CoAP. Next, we detail the definition and functioning of CoAP.