W3C home > Mailing lists > Public > public-wot-ig@w3.org > November 2016

AW: Regular Web of Things call on scripting API

From: Hund, Johannes <johannes.hund@siemens.com>
Date: Wed, 9 Nov 2016 11:55:15 +0000
To: Benjamin Francis <bfrancis@mozilla.com>
CC: "Kis, Zoltan" <zoltan.kis@intel.com>, Dave Raggett <dsr@w3.org>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <C271054E16F8474D9104E1146C767BF1773A21@DEFTHW99EK1MSX.ww902.siemens.net>
Dear Ben,

> [...] When you have a
> browser engine every problem looks like a DOM API. If we built Firefox OS again
> today we would implement the hardware APIs as web services on the server side
> of the web stack which web applications can interact with via a REST interface.
> Not as JavaScript APIs.

Exactly what you describe here is what we propose.
Instead of having a "physical API" to access local hardware next to the client and server-side APIs, we propose to treat the local hardware as "Things" that you interact with in the same way as you interact with "Things" on remote hosts.
This forms an architecture of microservices or "Things" with a standardized way to access & expose them. - a web of things.

> I'd suggest that a language-agnostic local scripting API for programming connected devices has nothing to do with the web 

It is an API for consuming and exposing REST APIs rsp. Web services - I am not sure why this has nothing to do with the web?

> Anyone can create a helper library to call a REST API using their
> language of choice.

No one hinders you from doing so, however, I do not see the argument why this defies the sense to define a standardized API.

Anyone can also write a web client, still it made sense to standardize the APIs you can expect in a w3c compliant browser.
As a web developer you would not want to write the same page ten times for every browser out there.

Best regards,
Received on Wednesday, 9 November 2016 11:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:08 UTC