Re: Regular Web of Things call on scripting API

On 1 November 2016 at 14:31, Dave Raggett <dsr@w3.org> wrote:

> How would your proposal decouple application scripts from the platform’s
> choice of protocols, given that REST and HTTP isn’t always appropriate?
>

My view is that the Web of Things should be built on URLs and HTTP rather
than trying to be entirely application protocol-agnostic (which I don't
think is realistic or even technically possible). That's what makes it the
Web of Things as opposed to the Internet of Things.

By using a single application protocol and data model the Web of Things can
be a unifying layer on top of the Internet of Things, devices can use
whatever network protocol meets their needs (and even use another IoT
application protocol behind HTTP which is bridged to the web via a gateway
or cloud service).

Pretty much any scripting language or application framework supports HTTP,
so you can use whatever language you want to call a REST API.


> In my own NodeJS based project, I provided an API for servers to expose a
> new thing, and another for clients to create a local thing as a proxy for a
> thing hosted on a remote server. For the first case I have:
>
>      wot.thing(name, model, implementation)
>
> where name is a string, model is a JSON object with declarations for
> properties, actions and events, and the implementation is a JSON object
> with named functions start(thing) and stop(thing). The server exposes the
> new thing, appending the thing’s name to the server’s configured base URI.
> The app provided start method is responsible for initialising the values of
> the properties and for providing implementations for the actions. For a
> sensor app, the implementation defines a means to update properties from
> the sensors, e.g. using a timer to read the sensor every second.
>
> The API for registering a proxy for a remote thing is a method that is
> passed the URI for the thing’s description, and call backs for success and
> failure. The success call back is passed the newly created object for the
> thing. A related case is where a gateway behind a firewall wants to publish
> a thing it hosts on a public cloud server.
>

I don't think I fully understood this, but it sounds complicated.

Why can't I just...

POST http://mythingserver.com/things/

...with a Thing Description of the new Thing including that it's a
temperature sensor with a temperature value. Then...

GET http://mythingserver.com/things/temperatureSensor/properties/temperature

... with the programming language of my choice.

There are many existing solutions for proxies or traversing firewalls with
HTTP.

I don't understand why any of this requires standardising a
language-agnostic scripting API via the W3C vs. just allowing anyone to
write their own helper library that talks to a standardised REST API?


> The Current Practises document covers the experiments used in the
> plugfests, but we lack a formal use cases and requirements study for
> scripting APIs, and I believe that that would help with the discussion over
> design choices.
>

Yes, I am yet to see any use cases which seem to justify a separate "WoT
Interface" and "Scripting API" as W3C specifications.

Ben