RE: Devices as Virtual Web Services

Hi,

I have so far been quit regarding the discussion on REST APIs. However, I have followed the discussion with great interest and I have made the following conclusions regarding the REST approach.

Implementing local device APIs through a local web server / REST seems as an attractive and flexible implementation solution. The device services are accessed by the local web server through native device APIs and are accessed by the browser or widget engine through http/REST. When new device APIs should be added the local web server is updated and downloaded to the device and updated JS libraries/frameworks are used. 

Accordingly: Web Apps API extensibility is (ideally at least) achieved without the need to update the browser/widget engine or any native device code under the condition that the device's native APIs are powerful enough.

However, the question remains: What should be standardized, the "JS level" or the "REST level"?

It seems to me that there are advantages in standardizing the REST level. In the discussion the following have been mentioned:

- REST APIs are language independent
- A REST API to a service situated "anywhere" (device, accessory, PC, server) can be accessed from "anywhere"
- REST APIs make it possible to leverage on existing HTTP access control mechanisms
- Developers use JS APIs, which hide the complex "REST coding", within their favorite JS library/framework anyway and these should not be standardized. 

My guess is that the REST approach is evolving within the web. However, we also have JS API standards/implementations such as Bondi, JIL, Symbian WRT, Phonegap etc. 

So, once again, what should DAP standardize? Are W3C now ready to take the step towards a full "REST approach" or should we for now stick to pure JS APIs and see the REST level as a future step? 

If we do not specify the REST level will this happen anyway in a "non-W3C manner"?

As a conclusion I would give a precautious support for a REST approach, at least for the APIs where it can bring added value, e.g. for services that can reside in the device as well in the network (Calendar, Tasks, Contacts, and Gallery as suggested by Robin). However, the question is whether we should switch to a REST level approach now or whether we should keep the pure JS track and consider the REST level as a next step.

Your humble
  Claes


> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Arve Bersvendsen
> Sent: tisdag den 2 februari 2010 09:07
> To: Max Froumentin; Robin Berjon
> Cc: public-device-apis@w3.org
> Subject: Re: Devices as Virtual Web Services
> 
> On Wed, 20 Jan 2010 18:03:03 +0100, Max Froumentin <maxfro@opera.com>
> wrote:
> 
> [Also note that this is a response to ACTION-84, I'm hanging my answer
> off
> Max's, because it's partially already in alignment with it]
> 
> > On 20/01/2010 15:32, Robin Berjon wrote:
> >> Hi all,
> >>
> >> as discussed previously, here are my notes about this specific issue:
> >>
> >>    http://dev.w3.org/2009/dap/docs/virtual-ws.html

> >>
> >> Comments welcome!
> >
> > DAP as an API means:
> > - It is implemented in the browser code, or a plugin
> > - It is simple to use for webapp authors (because it was designed so)
> 
> - The API can be designed specifically around the problem it intended
> to
> to solve.  With REST you have to create the API around two constraints:
> What you are intending to do, and REST itself.
> 
> > DAP as a REST service means:
> 
> * DAP as REST also requires that a discovery mechanism is specified
> * Error handling needs to be defined in terms of http
> * Access control needs to be specified in terms of the same-origin
> policy
> and CORS.
> 
> > - more work for webapp authors (and there are thousands more of them
> > than browser implementers.)
> 
> > - hence, webapp authors will almost be forced to use a framework
> 
> > - that framework will probably need to include Comet support
> 
> Note that "including Comet support" pretty much would mean that a
> solution
> is pretty much equivalent to ditching REST.
> 
> > - we're not sure yet if every feature of DAP is mappable to a REST
> > concept.
> 
> If all you have is a hammer, every problem looks like a nail. I don't
> neccesarily think it is a good idea, though.  It would feel downright
> painful to do POST to a camera to set the aperture or iso.
> 
> > - we're not sure how to solve the URI scheme problem.
> 
> The URI scheme problem is probably best solved by not actually creating
> a
> new scheme.  The downside to that is that we would probably need to
> (ab-)use http for the purpose. The upside to http is that you can, when
> suitable, expose services to a local network.
> 
> > Based on the above, and on the assumption that DAP is meant to be a
> > convenience for webapp authors, APIs seem simpler and superior.
> 
> I fully agree with that.
> 
> > But like John Kemp has said, it's a good thing to keep REST
> > implementations in mind when we design the API, since we can expect a
> > few of them to be wrappers around REST APIs anyway.
> 
> Agreed.
> 
> > Whether we should have a REST solution defined on top of the current
> API
> > is something we may want to have a look at, but not a priority to me.
> 
> Agreed.
> --
> Arve Bersvendsen
> 
> Opera Software ASA, http://www.opera.com/

Received on Wednesday, 10 February 2010 11:42:30 UTC