- From: Michael Koster <michaeljohnkoster@gmail.com>
- Date: Mon, 7 Nov 2016 21:44:40 +0800
- To: "Kis, Zoltan" <zoltan.kis@intel.com>
- Cc: Benjamin Francis <bfrancis@mozilla.com>, Public Web of Things IG <public-wot-ig@w3.org>
- Message-Id: <43F1A8BF-914D-4EAE-8AAA-75BEF8E70515@gmail.com>
Yes, I started a project to use iot-rest-api-server with iotivity and node-iotivity to build a WoT servient based on Iotivity. The idea is to use OCF as the REST API and use Thing Description as a hypermedia controls framework. https://github.com/connectIOT/iotivity-servient/blob/master/docs/st-servient.pdf <https://github.com/connectIOT/iotivity-servient/blob/master/docs/st-servient.pdf> I was hoping to motivate some enhancements to TD like collections and other hypermedia design patterns. Not much progress as I got involved with other things, but it seems like a sound concept. Best regards, Michael > On Nov 7, 2016, at 9:12 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote: > > > > On Mon, Nov 7, 2016 at 2:43 PM, Benjamin Francis <bfrancis@mozilla.com <mailto:bfrancis@mozilla.com>> wrote: > Do you imagine this API being implemented on the client side (e.g. as a DOM API in a browser engine) or on the server side (e.g. as a Node module)? If it's the former, has any browser vendor expressed an interest in implementing this? > > The ExposedThing interface is on server (sensors, actuators) side, in order to facilitate writing support for new Things. We do have an implementation to a very similar API (OCF) in a constrained JS runtime (based on JerryScript) that runs even in MCU's. > https://github.com/01org/zephyr.js/ <https://github.com/01org/zephyr.js/> > > > If it's the latter, what is the benefit of standardising this scripting API? Calling a REST API is likely to work differently in different languages, of which JavaScript is just one. > > The client side interface is a ConsumedThing, and could be in fact a library on top of REST. Anyone can replace it, i.e. no need to standardize, but it would be nice however. > > Then, nobody prevents standardizing scripting for other languages. > > We agree that the mother of all is the REST API. > > > Rather than specify the scripting API, have you considering specifying the REST API in terms of methods, requests and responses instead like the OCF does? > > We do have a REST API server, and I could imagine WoT comes up with a similar (but higher level) solution. > https://github.com/01org/iot-rest-api-server/ <https://github.com/01org/iot-rest-api-server/> > > The draft I created is deliberately based on REST model (and connected to OCF implementation, although not the same). > > Note that the links above point to OCF implementations, not WoT implementations. Nevertheless, we do plan to support WoT scripting, once there are concrete use cases and a scripting API draft that addresses those use cases. > > We have discussed these in today's Scripting API meeting. > > Best regards, > Zoltan >
Received on Monday, 7 November 2016 13:45:17 UTC