Re: ACTION-85: BONDI's investigation into LREST vs "conventional" JavaScript APIs

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?


On Tue, Jan 26, 2010 at 6:08 PM, Tran, Dzung D <> 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:
> [] On Behalf Of Paddy Byers
> Sent: Tuesday, January 26, 2010 04:03 PM
> To: 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://
> 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