Subject: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful?

From: mike amundsen <[email-masked]>
Date: Thu, 7 Apr 2016 16:47:25 -0400

This is a follow up on the convo today at IET around
draft-keranen-t2trg-rest-iot-01.

Rather than casting IoT style guidance as a copy of (some or all) of REST,
I suggest we create IoT-specific architectural style guidance. REST is the
style used to describe WWW, not IoT.

To do this, I suggest we identify System Properties and Constraints to
induce them.  This is what Fielding describes in chapter 2[1] as his method
of developing the REST style from chapter 5[2].

This would change the document from a description of Fielding's REST to a
description of An IoT Architectural Style. Of course, it is likely that
some (many?) of Fielding System Properties are compatible w/ IoT. But some
may not and creating an IoT specific style will reduce the occurrences of
discussions on whether IoT is "RESTful"

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm
[2] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

mamund
Mike Amundsen
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 7 Apr 2016 21:22:01 +0000

Dear Mike

> Rather than casting IoT style guidance as a copy of (some or all) of REST, I suggest we create
> IoT-specific architectural style guidance. REST is the style used to describe WWW, not IoT.

Here I disagree: REST is a style for networked software that was derived from the Web and idealized. Large parts of the Web do not even follow the constraints (see all the "RESTful API" that are more like RPC over HTTP). So, REST was already a step toward what you are recommending.

> To do this, I suggest we identify System Properties and Constraints to induce them.  This is what
> Fielding describes in chapter 2[1] as his method of developing the REST style from chapter 5[2].

> This would change the document from a description of Fielding's REST to a description of An IoT
> Architectural Style. Of course, it is likely that some (many?) of Fielding System Properties are
> compatible w/ IoT. But some may not and creating an IoT specific style will reduce the occurrences
> of discussions on whether IoT is "RESTful"

A Problem is that many of Fielding's concepts are misunderstood or used incorrectly to cut corners. We want to make sure they are used correctly, since we also see them useful for the IoT. We do not want to fight religiously about "RESTful or not RESTful"; we want to help, so that the useful pieces are used correctly (and are actually useful).

Yet I agree that some things are different in the IoT and that those need to be reflected in the document. We decided on a "two step program" here: First create a common understanding of "REST as we use it" and then progress to "Beyond REST".

Since CoRE and the T2TRG somewhat dedicated themselves to adopt the REST style to the IoT, we do not want to start from scratch and come up with a new style. As feedback for us, may I paraphraze your mail maybe as "do it a bit less by the book" (i.e., Roy's thesis) and focus a bit more on the current situation (which, for instance, includes using the language that has become common today; cf. Bob's comment in the T2TRG session)?

Best regards
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 07 Apr 2016 18:32:56 -0300

Hi Mike,

thank you for your input.
The Internet/Web of Things can very much be part of the greater Web (as
long as that is not equated to the Browser Web), but you are right that
not all of the constraints described by Fielding apply or are even
possible.  E.g., the use of mobile code on the Web of Things is
currently not a mainstream approach.  Since the IoT needs to be secure,
we also need better ways to include caches than are available in HTTP(S).

Indeed, an objective of the work here is to describe a form of REST that
is appropriate for IoT.  This requires us to find out what parts of REST
work (and are beneficial!) for the IoT and which parts aren't or need to
be modified.  In CoRE, we already have added notifications to the CoAP
protocol; this goes beyond REST as originally defined.

One other use of a document describing the use of REST in the IoT (WoT)
is that it can be used to create awareness that the REST style
(appropriately adapted) can be beneficial in the IoT.

Exercise for the reader: find a good name for the IoT-adapted variant of
REST.

Grüße, Carsten

---

From: mike amundsen <[email-masked]>
Date: Thu, 7 Apr 2016 18:30:07 -0400

Carsten/Kovatsch:

First, fine session today in the t2trg room. thanks for that.

Now, I am not suggesting we NOT adopt *any* of Fielding's Constraints
(there are ten[1] to consider). But we should keep in mind that the ten
*requirements* (think 2119 words) he selected are based on the 16
Architectural Properties of Key Interest [2] Fielding identified in Chapter
2. IoT might not share all those desireable properties and some IoT ones
might be missing from Fielding's WWW-inspired list.

As a simple exercise, we can tick down the list of ten Constraints and see
what 2119 words we want to invoke in our guidance document.

here's my straw-man:

*** Applying Fielidng's Constraints to IoT using RFC2119 Words ***
Client-Server :  MAY
Stateless : SHOULD
Cache : MUST
Uniform Interface : MUST
Identification of Resources : MUST
Manipulation of Resources through Representations : MUST
Self-Describing Messages : SHOULD
Hypermedia as the Engine of App State : MAY
Layered System : MUST
Code-On-Demand : MAY

Now, rather than say "is it RESTful" we can look at this list and start
asking about the value of each of these ten constraints when it comes to
IoT. Even more important, I suspect that there are constraints *missing*
from this list that would be important to IoT.

And we haven't even started on the list of Properties of Key Interest for
IoT.

BTW - naming is fun. I toss out IoTA for Internet of Things Architecture<G>

Cheers.

[1]
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1
[2]
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3

mamund
Mike Amundsen
+1.859.757.1449
skype: mca.amundsen

---

From: Michael Koster <[email-masked]>
Date: Thu, 7 Apr 2016 15:48:41 -0700

Hi,

Can you please copy the original correspondence to the list? This looks like a very interesting discussion; unfortunately I can't see the context so don't feel like joining though I have some comments regarding Fielding's approach and what we can learn.

Thanks,

Michael

> On Apr 7, 2016, at 2:22 PM, Kovatsch Matthias <[email-masked]> wrote:
> 
> Dear Mike
> 
> _______________________________________________
> T2TRG mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/t2trg <https://www.irtf.org/mailman/listinfo/t2trg>

---

From: mike amundsen <[email-masked]>
Date: Thu, 7 Apr 2016 19:31:44 -0400

Michael:

there's not much missing from Matthias' reply but here's the original
posting:

https://mailarchive.ietf.org/arch/msg/t2trg/m2mscd-sD2gjAwOkt786J9EWHS8

mamund
Mike Amundsen
+1.859.757.1449
skype: mca.amundsen

On Thu, Apr 7, 2016 at 6:48 PM, Michael Koster <[email-masked]>
wrote:

> Hi,
>
> Can you please copy the original correspondence to the list? This looks
> like a very interesting discussion; unfortunately I can't see the context
> so don't feel like joining though I have some comments regarding Fielding's
> approach and what we can learn.
>
> Thanks,
>
> Michael
>
> Here I disagree: REST is a style for networked software that was derived
> from the Web and idealized. Large parts of the Web do not even follow the
> constraints (see all the "RESTful API" that are more like RPC over HTTP).
> So, REST was already a step toward what you are recommending.
>
> induce them.  This is what
> A Problem is that many of Fielding's concepts are misunderstood or used
> incorrectly to cut corners. We want to make sure they are used correctly,
> since we also see them useful for the IoT. We do not want to fight religiously
> about "RESTful or not RESTful"; we want to help, so that the useful
> pieces are used correctly (and are actually useful).
>
> Yet I agree that some things are different in the IoT and that those need
> to be reflected in the document. We decided on a "two step program" here:
> First create a common understanding of "REST as we use it" and then
> progress to "Beyond REST".
>
> Since CoRE and the T2TRG somewhat dedicated themselves to adopt the REST
> style to the IoT, we do not want to start from scratch and come up with a
> new style. As feedback for us, may I paraphraze your mail maybe as "do it a
> bit less by the book" (i.e., Roy's thesis) and focus a bit more on the
> current situation (which, for instance, includes using the language that
> has become common today; cf. Bob's comment in the T2TRG session)?
>
> Best regards
> Matthias
>
>
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>
>
>

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 8 Apr 2016 08:47:41 +0200

> approach and what we can learn.

Mike it seems that gmail classes your mails as spam, which could be the 
reason why Michael isn't seeing them.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se