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

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