AW: Regular Web of Things call on scripting API

Hi Ben,

> To explain, I think the use cases of both the "Scripting API" and the "WoT
> Interface" could be fulfilled by a single WoT REST API.

I think exactly the use cases are the important piece we should look at.
 If you consider only the use case "there is a thing that has a WoT-compliant HTTP/REST interface and I want to access it from my browser" it might seem too much effort to have a standardized API.

But consider you want to do that not from a browser but from a runtime on a home gateway - or from another thing 
* "the lights in the house should be switched on when I open my garage door" -> have a script on the door to send a  POST to the lights
* "my heating should be controlled with this temperature sensor to have 22 celcius" -> have a script on the temp sensor to turn the heating up or down (as shown on one of the plugfests) or have a script on the heating to poll/observe the sensor. Expose target value as property.

This is also why we proposed APIs for exposing things - "I want to be able to run a script on the Thing that exposes functionality to the outside world" and also  APIs for discovering things beside the client functionality.

> 
> For example, rather than a function call like:
> 
> WoT.createThingFromDescription({"name": "My Temperature Sensor", ...});
> 
> Registering a new Thing should be an HTTP POST request with a Thing
> Description in the body, e.g.:
> POST http://mythingserver.com/things

> {
>   "name: "My Temperature Sensor",
>   ...
> }

Maybe just some more explanation: In your example, what does the thing server do?
Is it relaying the calls to the sensor?
Or is the temperature sensor itself the thing server?

> There's nothing to stop someone from creating a helper library to call that REST
> API from a particular programming language, but I see no need to standardise a
> language-agnostic scripting API for this purpose. In fact doing so could be
> problematic (not all languages natively support the concept of Promises you're
> using for example).

I agree the point of being language-agnostic is indeed something we have to discuss.
So far the major requirement was to be able to provide the API also on small nodes such as microcontrollers - we have shown examples in LUA.
Js runtimes have gotten very small meanwhile, so maybe we could focus on JS

If we keep mind that if we can express the API in a C interface (and you can do that with promises) you can expose it in nearly all relevant languages.


> As I understand it this is how Google Weave and EVRYTHNG APIs work, and it's
> how other platforms work too (sometimes with a REST API being called behind a
> provided language-specific software library). It's also how I would expect Mozilla's
> implementation to work.

What I've seen from Weave (which is unfortunately not much) Brillo will be also need to be considered if you also consider logic on the things. 
It's true that EVERYTHNG's model is focused on integrating an existing thing into a cloud platform via its rest interface and not on thing-to-thing.

Maybe Dom can correct me, but from our discussions the scripting API work is complementing the Model.
 
You mentioned the software libs that allow you to access the resp. REST API. 
I do not see the advantage if each vendor needs to write a different one rather than having a standard and an adjacent OSS implementation - or I have to use a completely different one when I want to switch from Weave to EVERYTHNG or Mozilla or have to interact with things in the different platforms.

If you add the cases for *providing* the REST API and accessing the REST API from the devices of thousands of Thing vendors we came to the conclusion that there is a need for such an standard.

 Johannes

Received on Wednesday, 2 November 2016 11:24:01 UTC