Re: Regular Web of Things call on scripting API

Top posting with some more comments.
TL;DR: focus on REST now, derive scripting API[s] from RESTful design,
everything REST on the long run.

For more words, read on.

The OCF (Open Connectivity Foundation) is also specifying a REST API (RAML
definitions of the interfaces and data models available).
https://openconnectivity.org/resources

CoAP is used on constrained nodes where a TCP stack is hard to include, or
with specific real-time requirements,  but intermediary nodes (a.k.a.
gateway, or servient) can connect those to the REST of the world.

So what Dave said applies, other standardization groups are doing similar
things. But whatever the future direction with the Scripting API, IMHO it
would be good to *start* with defining a good open REST API for Things.

IIUR, in the ideal technical case of Ben's proposal, all Things would be
REST servers (even though that is not fully feasible today). Scripting APIs
could be used for implementing these.

So scripting APIs are not conflicting with REST, but the applicability and
exposure is more narrow. Ultimately they can be regarded as manufacturer
specific or internal interfaces. Of course it still makes sense to
standardize them once those interfaces are opened to various providers (and
IIUR that is a valid use case for WoT). At least a JavaScript API makes
sense, and IMHO it should be derived from a REST API (it already is).

Another point: the REST thinking may simplify some discussions in the
standardization process and provide more focus (e.g. concerning actions,
data models, etc).

Correct me if I am wrong, but I thought REST fulfills the points listed by
Dave:

On Wed, Nov 2, 2016 at 1:04 PM, Dave Raggett <dsr@w3.org> wrote:
> 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

But the next points are valid too:

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

Exactly that is to be figured out. Certainly we could do a generic RESTful
[scripting] interface on top of HTTP or UDP or other protocols, but we
could even do HTTP over UDP where it applies. The question is what do we do
with the smallest nodes. If we address that with an architecture model of
intermediaries/servients, I don't see WoT being much different than OCF. A
Scripting API (that can serve also as an OCF scripting API for instance)
can bail out from there, so we have a use case. But I agree main focus
should be on REST.

Best regards,
Zoltan


On Wed, Nov 2, 2016 at 3:06 PM, Poussa, Sakari <sakari.poussa@intel.com>
wrote:

> Hi,
>
>
>
> I have been talking with Zoltan about the WoT scripting API so I know a
> little bit about it but not much.
>
>
>
> However, I like the REST API model. The implementation behind the REST can
> be anything, Java, JavaScript, C++, etc. WoT should focus on creating a
> rich REST APIs for the things.
>
>
>
> Sakari
>
>
>
> On 11/1/16, 1:49 PM, "Benjamin Francis" <bfrancis@mozilla.com> wrote:
>
>
>
> Ben from Mozilla is still wondering whether we should standardize
> scripting API.
>
>
>
> 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.
>
> 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",
>   ...
> }
>
> 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).
>
> 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.
>
> Ben
>
>
>
>