Draft: draft-irtf-t2trg-rest-iot

Commentary: I extended the constraints sections ( 4.x ) with a paragraph on the role for IoT. This does not introduce the MAY / SHOULD / MUST levels by  , but starts a basis for reaching such as conclusion . 
 From WISHI hackathon breakout : Capture that constrained networks may split data from  -- they are still bound together , but not always sent together . 
 Minimal text under 4.2 Stateless with PR 
 Was addressed with 41 
 Sections REST constraints 
 Many points were moved to the corresponding issue . 
 Let 's pick the interesting discussion about the REST constraints here : I like the idea of revisiting the constraints . I am less sure of MAY , SHOULD , and MUST is the best taxonomy here . The experience from CoAP shows that it is most practical to have both roles simultaneously on a device . The division into client and server is still very useful because it declares which component had the initiative to do something , which is helpful for the visibility , but also accountability in " digital forensics " ( ? ) . When an IoT device has initiative ( because there is a user , e.g. , pressing a button , or it has some policy / rules / AI ) , it acts as a client . When a device offers a service , it is in server role . Both can happen on the same device There are not details in the mail why  picked SHOULD . One concern is of course efficiency and compact messages . Introducing state can help a lot here . I guess we need a proper evaluation of the desired properties enabled through statelessness and the advantages from breaking the constraint . Maybe helpful : FTP vs HTTP comparison about how filepath is conveyed . Yes , must be enabled whenever possible to protect constrained devices . This is a bit endangered through security , as transport layer security is currently predominant . Object security is quite interesting here . One should analyze how to enable caching for encrypted content that can be accessed by multiple participants . There should be guidance what trade - offs are made with respect to security , since cache - key options may not be encrypted ... Caching usually only makes sense when the data is used by multiple / many participants . In the IoT , it might make sense to cache also individual data to protect constrained devices . Here the explanation of the methods would fit , and why one should respect their properties ( no side effects with a GET ... ) . CoAP is collecting more methods ( FETCH , PATCH ) . Explain the different philosophy compared to RPC . Not sure how to understand this . Is this related to queries and FETCH ? Hmm . This simply results from the uniform interface and context - dependent meaning of methods . Should this be reinterpreted somehow ? An interesting point here could be the handling of events , that is state that is pushed from the server to the client and each individual notification is important and must not be lost ( which makes them different from Observe notifications ) . Partly , this is statelessness . The other part is not relying on implicit out - of - band information . That is , proper use of Internet Media Types ( and not just labeling everything app / json ) . IoT often has " dead ends " in the application : a sensor or actuator that does not link any further . For discovery , HATEOAS is still very important and I see a MUST there to enable loose coupling . Might this be related to sleepy devices ? Explicit delegation ? We have to find examples where this would apply , in particular since code is shipped from the server to the client . For instance , form checking is irrelevant in a Thing - to - Thing context . Preprocessing of data is interesting , but that should be done on the server side , which is the origin of data ( e.g. , a sensor ) . 
 Let 's start with having a short discussion paragraph about this under Sections 4.x 
 waiting to be merged .
This improves simplicity and visibility, as it is clear which
component started an interaction.  Furthermore, it improves
modifiability through a clear separation of concerns.
This improves simplicity and visibility (also for digital forensics),
as it is clear which component started an interaction.  Furthermore,
it improves modifiability through a clear separation of concerns.
In IoT systems, endpoints often assume both roles of client and
(origin) server simultaneously.  When an IoT device has initiative
(because there is a user, e.g., pressing a button, or installed
rules/policies), it acts as a client.  When a device offers a
service, it is in server role.
The scaling properties of REST become particularly important in
massive IoT scenarios where thousands or millions of IoT devices may
attempt to interact with a system at the same time.
For IoT, the scaling properties of REST become particularly
important.  Note that being self-contained does not necessarily mean
that all information has to be inlined.  Constrained IoT devices may
choose to externalize metadata and hypermedia controls using Web
linking, so that only the dynamic content needs to be sent and the
static content such as schemas or controls can be cached.
Caching usually only makes sense when the data is used by multiple
participants.  In the IoT, however, it might make sense to cache also
individual data to protect constrained devices.  Security often
hinders the ability to cache responses.  For IoT systems, object
security may be preferable over transport layer security, as it
enables intermediaries to cache responses while preserving security.
For a large number of IoT applications, the hypermedia controls are
mainly used for the discovery of resources, as they often serve
sensor data.  Such resources are "dead ends", as they usually do not
link any further and only have one form of interaction: fetching the
sensor value.  For IoT, the critical parts of the Uniform Interface
constraint are the descriptions of messages and representation
formats used.  Simply using, for instance, "application/json" does
not help machine clients to understand the semantics of the
representation.  Yet defining very precise media types limits the re-
usability and interoperability.  Representation formats such as SenML
RFC8428 try to find a good trade-off between precision and re-
usability.  Another approach is to combine a generic format such as
JSON with syntactic as well as semantic annotations (see I-
D.handrews-json-schema-validation and W3C-TD, resp.).
IoT systems greatly benefit from this constraint, as it allows to
effectively shield constrained devices behind intermediaries and is
also the basis for gateways, which are used to integrate other (IoT)
ecosystems.
As of today, code-on-demand has not been explored much in IoT
systems.  Aspects to consider are that either one or both nodes are
constrained and might not have the resources to host or dynamically
fetch and execute such code.  Moreover, the origin server often has
no understanding of the actual application a mashup client realizes.
Still, code-on-demand can be useful for small polyfills, e.g., to
decode payloads, and potentially other features in the future.