Subject: [core] CoRE and REST metacomment

From: Peter Bigot <[email-masked]>
Date: Mon, 25 Oct 2010 09:32:52 -0500

Thanks for the historical background.

REST is not a cult; it's a carefully defined technical term describing a set
of architectural constraints which, when followed, tend to produce
architectures suitable for a distributed hypermedia system like the
world-wide web.

It's also a buzzword, adopted by people who look at the success of the web
and conclude that, if they design a system that's "RESTful", it will be just
as successful.  I'm not speaking of CoRE; all kinds of initiatives jump on
the REST bandwagon.  Unfortunately, many people don't understand what
constraints REST imposes and why, or that their problem domain might be
better suited by a different set of constraints.  Classic failure of
requirements validation.

I wasn't present at the inception of CoRE, but it seems likely the
buzzword-sense of REST contributed to why REST made it into the working
group's title, when it really has little to do with the technical content
described in the charter.  An architectural style based on peer-to-peer
transactions that reference local state to reduce communications overhead
rather than hierarchical stateless client-server transactions would be far
more natural for many problems involving constrained nodes, such as wireless
sensor network applications and M2M building management communications.

Presence of the term certainly distracted me from the fundamentals of the
problem and, I think, had a slight negative influence on the final design.
There's no reason why the requirement to define an adaptation interface
compatible with REST over HTTP should have had significant impact on the
internal architecture, but I believe it did.

Peter

On Sun, Oct 24, 2010 at 4:32 PM, Zach Shelby <[email-masked]> wrote:

>
> On Oct 22, 2010, at 6:24 PM, Peter Bigot wrote:
>
> > Disclaimer: I have not changed my position that multicast with REST is an
> ill-defined concept.  This proposal came from my accepting the position that
> not everything CoAP enables has to be 100% consistent with REST.  Some of
> what falls out from things like applying CoAP to multicast addresses is very
> useful and worth adopting when REST is less important than efficiency.
>
>
> Just to synchronize... The intention of this WG was never to make CoAP 100%
> consistent with REST. That would be pretty hard considering there is no RFC
> defining what REST is exactly (seems to be some kind of cult...), the
> closest thing that we know is HTTP (which was very much designed for
> transferring hypermedia). The CoRE working group does aim to fit its work
> into the REST architecture, but I would say making CoAP (and the security
> work) useful for constrained nodes and networks in M2M applications to be
> our main goal. Thus I agree with you, multicast CoAP is worth developing,
> and is a must for most applications we are considering it for.
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>