- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 2 Feb 2010 21:23:34 -0800
- To: "Tran, Dzung D" <dzung.d.tran@intel.com>
- Cc: Paddy Byers <paddy.byers@gmail.com>, "public-device-apis@w3.org Device APIs and Policy Working Group WG" <public-device-apis@w3.org>
Why do we have to choose all-REST or all-WebIDL? Perhaps REST is more appropriate for some APIs, such as Contacts, whereas WebIDL is more appropriate for others, such as microphone? Adam On Tue, Jan 26, 2010 at 6:08 PM, Tran, Dzung D <dzung.d.tran@intel.com> wrote: > On point 3) about polling: Since to support REST, some type of local web > server would be needed, so can you use server-sent events instead of > polling? > > > > Thanks > > Dzung Tran > > > > From: public-device-apis-request@w3.org > [mailto:public-device-apis-request@w3.org] On Behalf Of Paddy Byers > Sent: Tuesday, January 26, 2010 04:03 PM > To: public-device-apis@w3.org Device APIs and Policy Working Group WG > Subject: ACTION-85: BONDI's investigation into LREST vs "conventional" > JavaScript APIs > > > > Hi, > > The points below summarise the results of the investigation conducted at an > early stage of the BONDI project when deciding whether or not to adopt a > REST style for its APIs. > > 1) Security/access control: one of the cited advantages of the REST approach > is that it reduces the access control problem to an existing problem, ie > which web applications are permitted to access which foreign sites. When we > discussed how to specify access control, we didn't really see how it helped. > The problem might be reduced to having policy-driven control over which web > applications (identified by URI (how for widgets?)) can access which remote > services (ie something like service://pim.contact/....) > > However, in the BONDI model we can have rules that identify/match web > applications by multiple attributes: author identity, distributor identity, > distributor certificate issuer, etc etc; and we can also have rules that > match resources at a fine-grained level too, down to the level of specific > invocation parameters. These capabilities are all motivated by specific > policy use cases. It is not at all obvious that the HTTP "standard access > control" mechanisms provide any abstractions or mechanisms that are > relevant. > > 2) Implementability: one of the cited advantages of the REST approach is > that different services are implementable without having to get into the > guts of the browser or Web Runtime. However, again, there doesn't seem to be > any advantage. Browsers don't have open extension points to allow > independent implementation of additional protocols. However, browsers do > already have the ability to plug in independently developed plugins, and > these are one means of supporting API extensibility. So, if anything, the > conventional API approach is more extensible than the REST approach. > > 3) Performance. Thinking about, for example, an accelerometer API which > needs to be polled at 20Hz, the REST approach seems to require a huge amount > of processing compared with something that only needs to be a single > property access. Although you can argue that modern embedded devices are > capable of doing all that work quickly enough, it is nonetheless grossly > ineffieicnt and will have a dramatic and avoidable effect on responsiveness > and battery life. > > 4) Emulatability. (At the time of our discussions, at least) conventional > APIs are potentially capable of emulation on top of the various proprietary > environments available (JIL and the vendor-specific environments), whereas a > REST API would not > > 5) Generality: it is clear that some APIs can be modelled very naturally as > REST APIs, but others are just not represented as naturally - for example > APIs involving multiple asynchornous callbacks (eg a Bluetooth device > discovery API). > > WebIDL is complex for a reason - because all of its various features (eg > value types vs passing by reference, properties vs methods, sync vs async > methods, etc) all emerge as being necessary when you try to define a complex > API. Although in the end any API is representable as a REST API, we thought > things would become more and more contrived. Artificially forcing every API > into the REST model just makes things more complex to define, and more > complex to use, without any obvious advantage. > > In the worst case we would end up with two sets of APIs, one set modelled as > REST and one modelled as conventional APIs. > > Overall, the only real motivation for the REST approach was because it > provided an obvious and non-disruptive implementation approach (ie literally > to implement via a local web server). However, when it became clear that > other implementation routes were available, and the resulting system would > be more efficient, more accessible for developers, and more easily able to > support the kind of access control model we believed to be necessary, then > there was a general consensus that it offered no advantage. > > Paddy
Received on Wednesday, 3 February 2010 05:24:33 UTC