XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


The Beauty of REST

The Beauty of REST

March 17, 2004

I've just been to SXSW to speak on a panel called Streetwise Librarians and the Revolution in Libraries. My own small contribution to that revolution, and the reason for my visit to SXSW, is the LibraryLookup project I launched 16 months ago. I'll admit that "project" is a lofty term for what is, basically, just a bunch of variations on a simple JavaScript bookmarklet. But for thousands of patrons of hundreds of libraries, that snippet of JavaScript -- which extracts the ISBN from an Amazon (or other ISBN-bearing) URL and checks for the book's availability in your local library -- has been an eye-opener.

Rekindled interest in local libraries is part of LibraryLookup's charm. In the ecommerce era, when any book is just a click and a Fedex shipment away, we tend to forget that access to library books is both free and immediate. You don't need to own every book that you read! Despite its anti-commercial overtones, though, I don't think LibraryLookup competes with booksellers in any serious way. Rather, I'd argue that by encouraging the habit of reading it can only help the booksellers' cause. In any case, promoting literacy isn't LibraryLookup's only agenda. It's also my best example of how RESTful systems enable ad-hoc integration, and of how, conversely, non-RESTful systems can thwart it.

There are a handful of major OPAC (online public access catalog) systems, and dozens of minor ones. I started with the major variants, and followed the usual recipe: first identify the URL that does what you want (in my case, search by ISBN), then repackage or parameterize the URL. It's helpful when the system you're working with uses HTTP GET and leaves the URL in the browser's location field ("URL-line"). But recovering the implicit URL that's hidden behind an HTTP POST gets easier all the time. My new favorite tool for that job is Chris Pederick's Web Developer Extension, an installable add-in for Mozilla-family browsers. Among many other conveniences, it will automatically convert between GETs and POSTs.

The use of POST rather than GET is a minor obstacle, but some other design choices are deal breakers. At least one OPAC, for example, presents its user interface in a Java applet, thereby foreclosing the possibility of Web-style integration. If there were Flash-based OPAC clients, they'd suffer from the same problem. The solution here isn't to eschew the rich client, but rather to build it on a foundation of XML services and to make sure those services are available to REST clients as well as to those using SOAP or some other flavor of XML over HTTP. If you're starting from scratch and want to use SOAP, make sure your SOAP toolkit supports the HTTP GET mode of access.

The use of session identifiers is another deal breaker. Some OPAC systems require them unnecessarily. If you want to review your account or renew a book, you've got to be logged in. But there's no need to identify yourself if you're only searching. Yet some OPACs establish session IDs for all activities, including anonymous search. This policy thwarts LibraryLookup. I could field a proxy service to handle the session-ID protocol, thus enabling the LibraryLookup bookmarklet user to have a one-click, no-hassle experience. But requiring a hosted intermediary throws cold water on spontaneous integration. The fewer moving parts, the better. The LibraryLookup project originally manifested itself as a handful of lists of prebuilt bookmarklets. When it became impractical to maintain those lists, I added a JavaScript-based build your own bookmarklet page that translates a domain name and an OPAC type into a LibraryLookup bookmarklet. But there are no dynamic services running in support of that page. That would be overkill for something as simple as splicing together two existing web-based services that share a common piece of metadata.

I've really enjoyed watching librarians grasp and apply this technique. There's a standing invitation, on the build-your-own-bookmarklet page, for new URL patterns that extend the list of OPACs. The contributions I've received have more than doubled the number of supported systems. Often the contributors are not particularly geeky. They're just librarians who are thrilled to be able to produce the key that unlocks a useful bit integration on behalf of the patrons of their libraries. It never would have occurred to them that cross-site integration can be a simple thing, requiring neither the explicit cooperation of the endpoint systems nor a propellerhead in the middle to wrangle things into place. But once they see that the integration tool can be a plain old URL -- something they know how to capture, alter, and reuse -- they're off and running.

Although librarians are pleasantly surprised by all this, I'd rather it were the other way around. I think librarians, like all users of web-based information systems, should be unpleasantly surprised when they find that their systems haven't been engineered in the common sense ways that make them friendly to ad hoc integration.


More from Jon Udell

Lightweight XML Search Servers, Part 2

Lightweight XML Search Servers

The Social Life of XML

Interactive Microcontent

Language Instincts

I do see hopeful signs. When I showed one librarian why her OPAC system wouldn't cooperate with LibraryLookup, she concluded that her vendor had used "the wrong kind of software." And I agreed. She has never read Roy Fielding's thesis and never will, but she groks the REST principles intuitively. What she was saying, thogh she lacked the terminology to describe it, is that her OPAC is broken because it's not RESTful. And if she has any say in the matter, the next OPAC her library buys will be.

The word used again and again lately to describe distributed information systems is "composition". The Unix idea of piecing together solutions from reusable parts has morphed into XML-based, service-oriented architecture. This time around, though, it's all happening on the Web, in an environment where everybody can compose simple and popular tunes. When technologists forget that, I hope users will administer the dope slap we deserve.

1 to 2 of 2
  1. article
    2007-07-28 14:33:04 profesjonalna
    • article
      2010-07-26 04:40:32 alice.thomas222
      • article
        2010-07-26 04:41:48 alice.thomas222
  2. Anonymous sessions
    2004-05-27 02:34:11 Owen Stephens
1 to 2 of 2