Include feedback by Mike Amundsen

[mkovatsc]

Sections

https://www.ietf.org/mail-archive/web/t2trg/current/msg00204.html

REST constraints

https://www.ietf.org/mail-archive/web/t2trg/current/msg00199.html

[mkovatsc]

Many points were moved to the corresponding issue.

[mkovatsc]

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.

Client-Server : MAY

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

Stateless : SHOULD

There are not details in the mail why Mike 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.

Cache : MUST

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.

Uniform Interface : MUST

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.

Identification of Resources : MUST

Not sure how to understand this. Is this related to queries and FETCH?

Manipulation of Resources through Representations : MUST

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).

Self-Describing Messages : SHOULD

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).

Hypermedia as the Engine of App State : MAY

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.

Layered System : MUST

Might this be related to sleepy devices? Explicit delegation?

Code-On-Demand : MAY

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).

[mkovatsc]

Let's start with having a short discussion paragraph about this under Sections 4.x

[mkovatsc]

41 waiting to be merged.