[Architecture] Device APIs: Javascript vs HTTP/REST client API interfaces - comment/feedback?

Dear TAG members:

The Device APIs working group is chartered  "to create client-side APIs that enable the development of Web Applications that interact with device hardware, services and applications such as the camera, microphone, system sensors, native address books, calendars and native messaging applications" [1].

For some time the working group has been considering two approaches toward this mission. The first, initial approach, has been to define Javascript interface definitions in WebIDL [2]. This has some advantages of familiarity and simplicity for Javascript developers and ease of specification.

We have received the suggestion to consider exposing these local capabilities using an HTTP-based REST approach, with reasons including the ability (a) to address both local and remote resources in a consistent and transparent manner, and (b) to leverage security approaches developed by others for the more general web case [3]. These suggestions have also been raised on the WebKit mailing list  [4]. We note that security and privacy solutions are not entirely defined by the web community for the HTTP/REST approach.

The previous DAP working group charter included work on a policy based control mechanism for local access, but this has been removed from the charter. One reason for dropping this was issues related to configuration and management of policy. Thus security and privacy are also mostly implementation dependent for the Javascript approach as well.

Although the DAP WG has focused on defining WebIDL interfaces to local resources, we  early on made the assumption that we should keep REST interfaces in mind and possibly bind the WebIDL to HTTP/REST as well as Javascript. The Javascript binding is defined in the WebIDL specification, while an HTTP/REST binding is an item that would require a formal definition.  Robin Berjon reviewed the possibility of binding to a REST approach and noted some potential issues, including lack of adequate support for publish-subscribe paradigm, issues related to caching, issues related to appropriate URI definition for local resources, and the potential cost of indirection [5].

We are now revisiting whether we can formally bind WebIDL successfully to an HTTP/REST interface, whether we should explicitly shift to an HTTP/REST based approach, or whether we should continue with the current WebIDL definitions that are easily bound to Javascript while working to define them so that it is possible to also define a REST interface independently but having a similar model.

Does the TAG have any additional advice or suggestions on the WebIDL/Javascript versus HTTP/REST architectural approach, the questions raised to date, other concerns and/or suggestions for binding WebIDL to an HTTP interface? Thoughts on security and privacy related to this choice are also welcome. (some earlier comments are noted in the earlier review [5])

We could use our Contacts interface definition as an example interface (editors draft) [6] if details are useful.

Discussion on the public DAP WG mailing list only might be appropriate, even though I cross-posted here.

thanks

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group

[1] http://www.w3.org/2011/07/DeviceAPICharter

[2] http://www.w3.org/TR/WebIDL/

[3] http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html

[4] http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html 

references https://lists.webkit.org/pipermail/webkit-dev/2011-July/017621.html

[5] http://dev.w3.org/2009/dap/docs/virtual-ws.html

[6] http://dev.w3.org/2009/dap/contacts/

For DAP Tracker, this should complete ACTION-441

Received on Friday, 2 September 2011 15:51:54 UTC