RE: [W3c WoT IG]: Review of "RESTful Design for Internet of Things Systems -draft"

Thanks for your replies to my comments Ari!

See my further responses inline below.

BR
  Claes


From: Ari Keränen [mailto:ari.keranen@ericsson.com]
Sent: den 3 november 2015 16:28
To: Nilsson, Claes1; 'public-wot-ig@w3.org'
Cc: Klaus Hartke; 'Kovatsch Matthias'
Subject: Re: [W3c WoT IG]: Review of "RESTful Design for Internet of Things Systems -draft"

Hi Claes,

Thanks for the feedback! Please see inline.

On 03/11/15 17:35, Nilsson, Claes1 wrote:
Hi Ari,

I hope that the IETF meeting last week was successful.

As promised I have read your document: https://tools.ietf.org/html/draft-keranen-t2trg-rest-iot-00 and have a few comments. However, they may already be obsolete due to your discussions at the IETF meeting.


·        Section 3.1, Architecture:
Not sure on the distinction between Forward Proxy and Reverse Proxy. As far as I understand an example of a Reverse Proxy is a HTTP-CoAP GW. But could examples of Forward Proxies be given? What does this mean for IoT systems? In figure 3 it is stated that the Origin Server is "Legacy System" but I assume that it could also be a normal web server?
HTTP-CoAP proxy could be forward proxy for a node in the constrained network using CoAP to access HTTP servers. For IoT systems this is a fairly common scenario (don't have enough resources to run HTTP on its own). We should indeed clarify this and add examples.

[Claes]: Ok but still not sure on the difference between a forward Proxy and a Reverse Proxy and the importance of this for IoT/WoT use cases but hopefully your next version of this document make that clearer.



·        Section 3.5 HTTP and CoAP methods:
Would be fine with tangible examples on methods used in IoT use cases. I can guess the following for an "Assisted Living" device that uses sensors to detect a fall and also has a vibrator. The device uses HTTP or CoAP to communicate with an application cloud server.

Cloud server --> device:
PUT /startFallDetection      ---   as a new PUT does not change the state (fall being detected) if a previous PUT already has been issued.
POST /vibrate    ---    as each POST creates a new vibration.

Device -> cloud server:
POST /fallDetected  --- as it is send every time a fall occurs

Am I correct?
The problem with these particular example usages is that they are "RPC like" (invoking methods), instead of RESTful (changing resource states). But yes, we should add examples to the methods. Will try to work something for the next version.

[Claes]: Yes, for such a use case a bidirectional communication channel, for example with Websockets, sending JSON-RPC calls in both directions would probably be a better choice. However, let us say that the IoT device is constrained and CoAP and REST have to be used. The non-obvious way of how to do this is probably the reason why this document is needed. We have "Actions" according to the Thing Description proposed by WoT-IG and these actions may be "RPC-like". Mapping this to REST would for an Action "vibrate" be mapped on CoAP like:

POST coap://www.example.com:5683/vibrator/vibrate
Payload
{
     "pattern": "string"
}

Also see the proposed REST mappings at the end of https://github.com/w3c/wot/blob/master/TF-TD/Tutorial.md (section CoAP Protocol Binding)

WDYT?


·        Section 3.5.3 PUT:
The sentence "Hence, the intent of PUT  is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server." Does not seem correct if HTTPS or CoAPS is used. Then the message is not visible to intermediaries.
Good point and should be clarified. This does actually apply also to HTTPS and CoAPS if the security is terminated in a proxy, but in general the intermediaries don't see the message if transport layer security is used. But object security changes this again.


Cheers,
Ari

Received on Tuesday, 3 November 2015 20:26:34 UTC