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