Re: Regular Web of Things call on scripting API

On 2 November 2016 at 11:04, Dave Raggett <dsr@w3.org> wrote:

> You’re welcome to that opinion. For me, the Web in the Web of things is
> about employing the core Web architecture:
>
>   1.  a means for addressing things
>   2.  machine interpretable descriptions of things and their relationships
> (i.e. links, forming a web)
>   3.  a suite of protocols for accessing things and their descriptions
>
> There are already many IoT platforms and protocols, and defining one more
> competing platform won’t really help with addressing the fragmentation into
> an archipelago of incompatible solutions.  This is why it makes sense to
> learn from the success of the Internet as a means to enable end to end
> messaging across different network technologies. We need to define an
> abstraction layer that complements  rather than competes with the range of
> IoT platforms and protocols. I expect that HTTP will play an important
> role, but don’t see the benefit of excluding other protocols, and forcing
> them to the network edge as it were.
>

> The vision of the Web of things as an abstraction layer is future proof in
> that it will scale to new requirements as different groups of people apply
> it to widely different application domains. For example, cyber-physical
> systems may impose real-time requirements for which HTTP is a poor fit. In
> other cases involving data streaming, where the loss of the occasional data
> point isn’t critical, then UDP based protocols may make the most sense.
>
> So to move forward, can we agree to support HTTP, but not to rule out
> other protocols where those are needed to address requirements for which
> HTTP is a poor fit?
>

I think there's potentially an argument for defining a CoAP binding given
that CoAP is so similar to HTTP but has benefits for resource constrained
devices which are likely to be common on the Internet of Things, at least
until it becomes more clear whether CoAP or HTTP/2 will dominate in this
area.

CoAP is built on RESTful principles so it has URIs, a request/response
pattern and GET, PUT, POST and DELETE methods just like HTTP. Trying to
define bindings to other non-Internet non-web application protocols like
ZigBee or X10 is probably futile.

I'd suggest the most likely outcome of trying to be application
protocol-agnostic is that you don't actually improve interoperability
because even if all existing application protocols adopt a new standard
data model (very unlikely), everything is still using different protocols
that need translating somehow. Even a REST API over CoAP using the WoT data
model will need bridging to HTTP in order for a web application to call it
from client-side JavaScript.

So yes, I agree the specification could allow for other protocol bindings
for protocols which can support a REST API, but the focus should be on
defining a REST API with a default HTTP binding and a default JSON
encoding, possibly with additional notes describing a CoAP binding and CBOR
encoding for example.

I don't think standardising a language-agnostic scripting API which calls
the REST API is necessary.

Ben