Re: Devices as Virtual Web Services


Thanks for your message.

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

Is the executive summary here:

1. Standardize Javascript APIs for all device functionality in the  
DAP charter

2. Expose REST interface to those APIs where appropriate, using those  
APIs to implement

Further, do #1 first.

Is that a correct summary of what you suggest?

regards, Frederick

Frederick Hirsch

On Feb 10, 2010, at 6:41 AM, ext Nilsson, Claes1 wrote:

> 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: [mailto:public-device-apis-
>>] On Behalf Of Arve Bersvendsen
>> Sent: tisdag den 2 februari 2010 09:07
>> To: Max Froumentin; Robin Berjon
>> Cc:
>> Subject: Re: Devices as Virtual Web Services
>> On Wed, 20 Jan 2010 18:03:03 +0100, Max Froumentin <>
>> 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:
>>>> 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,

Received on Wednesday, 10 February 2010 11:50:13 UTC