Re: Devices as Virtual Web Services

FWIW, REST is an architectural style optimized for very large scale,
network based systems, and many of its constraints make little sense
in a local environment.  I speak from experience here, having gone too
far along these lines in a project I started at an old startup of mine
back in 2001, developing a Web server for Blackberry devices.

That said, I think there are some lessons that REST has taught us that
can be applied to the "device APIs" space (and haven't yet, AFAICT).

The big one is generality of interface; that the more reusable the
interface, the simpler it is for developers to use.  Although I
haven't had the time to speak up here, I'm saddened that the default
approach taken to date to providing access to some local feature is
simply to propose a new, one-off API, rather than looking to perhaps
reuse an existing API.  In fact, there's already a very general,
reusable API that's very well known by developers and can provide for
read and write access to a wide variety of functionality. Before I
name it though, I wanted to describe another example of this; the
ProcFS pseudo file system popularized by Linux as /proc.  By mapping
internal machine information into the canonical Unix abstraction, the
file, suddenly this information became easily accessible to developers
using existing file based tools such as grep, as well as to new
scripting languages that didn't have a wide variety of OS-specific
libraries, but instead just access to open().  So what is the
equivalent common abstraction for Web developers?  I believe it's the
document, and so the reusable document API I had in mind was the DOM.

Granted, it's not suitable for everything, but it seems to me that
there's some low hanging fruit such as the System Info API that could
be easily done via the DOM.  Of course, choosing the DOM doesn't solve
all our problems as we still need to decide whether we use the HTML
DOM and then encode the data in microformats/RDFa, or use the XML DOM
and develop a custom vocabulary (hopefully a reusable one)?  There's
also the granularity issue; because of the quantity of system
information available, surely having just one SysInfo document object
would be clumsy, so what pieces do we grant full document-hood to?

Another important lesson to be taken from REST, and one that has been
mentioned here; giving this information URIs.  I agree that this is
valuable, but I'm not sure that it's as high a priority as getting the
APIs right because I'm not aware of any use cases that require it.
But, that said, once you've identified your document objects, then
you've also identified your resources and all you're left with is
mapping your objects to resources, e.g. SysInfo.CpuDetails to


Received on Wednesday, 27 January 2010 16:36:50 UTC