Re: Regular Web of Things call on scripting API

Informational post.

Note this recent IETF Draft, where they define REST around operations in
both http(s):// and coap(s)://

https://www.ietf.org/id/draft-keranen-t2trg-rest-iot-03.txt

Regards,
D.

On Wed, Nov 2, 2016 at 12:56 PM, Benjamin Francis <bfrancis@mozilla.com>
wrote:

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