Draft: draft-keranen-t2trg-rest-iot

Commentary: Changed Section System Design and started design pattern on Calling a Function .
When designing a RESTful system, the state of the distributed
application must be assigned to the different components.  Here, it
is important to distinguish between "client state" and "resource
state".
When designing a RESTful system, the primary effort goes into
modeling the state of the distributed application and assigning it to
the different components (i.e., clients and servers).  How clients
can navigate through the resources and modify state to achieve their
goals is defined through hypermedia controls, that is, links and
forms.  Hypermedia controls span a kind of a state machine where the
nodes are resources and the transitions are links or forms.  Clients
run this state machine (i.e., the application) by retrieving
representations, processing the data, and following the included
hypermedia controls.  In REST, remote state is changed by submitting
forms.  This is usually done by retrieving the current state,
modifying the state on the client side, and transfering the new state
to the server in the form of new representations - rather then
calling a service and modifying the state on the server side.
Client state encompasses the current state of the described state
machine and the possible next transitions derived from the hypermedia
controls within the currently processed representation (see sec-
terms).  Furthermore, clients can have part of the state of the
distributed application in local variables.
Resource state includes the more persistent data of an application
(i.e., independent of individual clients).  This can be static data
such as device descriptions, persistent data such as system
configurations, but also dynamic data such as the current value of a
sensor on a thing.
Resource state includes the more persistent data of an application
(i.e., independent of the client control flow and lifetime).  This
can be static data such as device descriptions, persistent data such
as system configuration, but also dynamic data such as the current
value of a sensor on a thing.
The GET method requests a current representation for the target
resource.  Only the origin server needs to know how each of its
resource identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of
the target resource in a response to GET.
The GET method requests a current representation for the target
resource, while the origin server must ensure that there are no side-
effects on the resource state.  Only the origin server needs to know
how each of its resource identifiers corresponds to an implementation
and how each implementation manages to select and send a current
representation of the target resource in a response to GET.
To modify resource state, clients usually GET a representation from
the server, process it locally, and transfer the resulting state back
to the server with a PUT.  Sometimes, however, the state can only be
modified on the server side, for instance, because representations
would be too large to transfer or part of the required information
shall not be accessible to clients.
In this case, resource state is modified by calling a function.  This
is usually modeled with a POST request, as it leaves the behavior
semantics completely to the server.