mjCoAP: An Open-Source Lightweight Java CoAP Library for Internet of Things Applications - Interoperability and Open-Source Solutions for the Internet of Things - page 120

interact with CoAP servers through the mediation of “ HTTP-to-CoAP proxies ”,
which map HTTP requests to CoAP requests and CoAP responses to HTTP
responses. Rules for HTTP-to-CoAP mapping are being defined in a specialized
draft [ 12 ].

2.3 CoAP Extensions

Besides the CoAP specification, the IETF CoRE WG is also defining additional
drafts in order to address some issues that CoAP does not take into account.
The Block Option [ 13 ] is introduced to allow the transmission of payloads of
arbitrary size. In fact, the use of UDP introduces a restriction on the maximum
size of the payload that can be sent within a CoAP message. Moreover, since
CoAP is intended to be used by constrained devices, it might happen that the
endpoints of communication do not have enough resources to handle payloads of
certain sizes. This option is therefore used to split payloads into chunks, which
are going to be sent in sequence of messages, each carrying a single chunk. The
Block Option draft provides mechanisms so that a client and a server are able
to negotiate the chunk size, according to their capabilities.
The Observe Option [ 14 ] has been designed to allow resources to be observed.
Observing resources introduces a new communication model, which differs from
the traditional request/response (polling). When a client is willing to observe a
resource, it sends a GET request for a given resource and includes an Observe
option. The server sends a response with the requested resource and registers the
client as subscribed to receive notifications upon changes of the resource state.
When the state of the observed resource changes, the server sends a new response
with the updated resource. Therefore, a single request can result in more than
one response being received by the client, thus implementing a publish/subscribe
communication model.
The Resource Directory (RD) [ 15 ] hosts descriptions of resources held on
other servers, allowing lookups to be performed for those resources. The draft
describes the interfaces to register, maintain, lookup and remove resources
descriptions. A RD can used by applications as a means to discover services
and resources in a standardized way, based on Web Linking [ 16 , 17 ], allowing
applications to discover resources dynamically. The RD is reachable in a stan-
dard and uniform way by accessing the

URI.

/.well-known/core

3 Related Work

The RESTful architectural style has been conceived to web (HTTP-based) appli-
cations, in order to provide a set of rules intended to promote software longevity
and independent evolution, by minimizing interdependence between client and
server applications. RESTful applications are therefore intrinsically resilient to
changes that might occur over time. Such an approach is particularly suitable
for IoT and Machine-to-Machine (M2M) applications, since these kinds of sys-
tems comprise nodes that might be deployed to unattended locations and require