W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Simple LREST toying

From: Robin Berjon <robin@robineko.com>
Date: Thu, 11 Feb 2010 17:22:51 +0100
Message-Id: <9770E408-98BD-4DBD-98CE-1D2788E8BA70@robineko.com>
To: public-device-apis@w3.org

just to help clarify some ideas around LREST I put together a really dirty and really ugly implementation of what a Gallery API could be. It's up at:


(Note: it works in the latest FF, Safari, Chrome; not in the latest Opera; untested on IE)

The only real browser-level change that is makes is that navigator.services.galleries is made to contain a list of galleries for discovery. Each is described thus:

interface Gallery {
  readonly attribute DOMString name;
  readonly attribute DOMString uri;

If you click on the button to list the galleries it does so. The URIs that they use are "magic", i.e. they have the form "unicorn:flickr/tag/dahut" (I picked unicorn, of course it could be anything).

The rest of the code just makes regular XHR/AJAX calls to that URI, it just so happens that they become intercepted and transparently get an answer that matches the request, so "unicorn:flickr/tag/dahut" will get you a bunch of images tagged as "dahut".

This is implemented by wrapping around the native XMLHttpRequest and taking over for the unicorn: URIs. XHR requests to regular URIs are undisturbed (as can be tested). Below the hood it calls out to Flickr's API, but that's just a detail: it could just as well be local or another remote source.

It makes use of a fake Infobar to show how, if the service is implemented by the browser itself, it can be integrated with the existing flow.

This only does a simple GET, but obviously it could work with other methods.

So overall nothing Earth-shattering, but it might clarify how this could work in our collective mind. I'd be interested in hearing how some might plug better auth on top of this (feel free to hack on it in CVS).

Robin Berjon
  robineko  hired gun, higher standards
Received on Thursday, 11 February 2010 16:23:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC