The name game
Should the URI namespace be opaque?
Follow @infoworldOver the weekend my LibraryLookup[1] project stirred up some action on rest-discuss, the Yahoo Groups forum that's dedicated to sorting out the architectural style called REST (Representation State Transfer).
At issue was whether, as Tim-Berners Lee once prescribed[2], a Web application's URI namespace should be opaque. If that axiom holds, it wouldn't be kosher to do what I did: Extract an ISBN from an Amazon URI and inject it into another application. But Roy Fielding, who is co-founder of The Apache Software Foundation, chief scientist at Day Software, and author of the doctoral thesis on REST which provoked the Web services movement to rediscover its roots in the Web, weighed in with this opinion[3]:
"REST does not require that a URI be opaque ... In fact, RESTful applications are, at all times, encouraged to use human-meaningful, hierarchical identifiers in order to maximize the serendipitous use of the information beyond what is anticipated by the original application."
REST guru Mark Baker added[4]:
"I thought long and hard about this recently due to Jon Udell's ISBN-in-the-URI javascript hack. There's no denying the value in that."
And Bill de hOra[5], a contributor to the discussion group, said:
"Jon has ... received near-universal acclaim ... If you buy into TBL's strong claim (URI opacity is an axiom) or Paul Prescod's weaker variant (peeking into URIs is a bad idea), then what Jon's done is a nasty hack (a la screenscraping), and not as popular opinion has it, a neat hack. Either way, this hack seems to offer considerable, immediate, utility."
To be honest, I've sometimes had trouble following the ongoing REST debate. But the words "value" and "utility" come through loud and clear. Of course, LibraryLookup is hardly the first demonstration of such value and utility. Consider, to take just one example, Erik Benson's All Consuming[6], an aggregation service that gathers Weblog postings about books. It depends in two ways on a URI pattern that includes an ISBN. When it scans Weblogs, it relies on that ISBN to identify entries that refer to books. Its own pages, in turn, use the ISBN to create referrals back to Amazon. Such linkage is, of course, the entire foundation of the Amazon Associates program.
It seems unlikely that Amazon's ISBN-in-the-URI pattern would change. But let's not lightly dismiss Berners-Lee's opacity axiom. Its intent was to ensure that a service provider can always reorganize a namespace without fear of breaking clients that depend on that namespace. In fact, the LibraryLookup project raised an issue that could warrant such reorganization. As librarians well know, the ISBN is specific to an edition of a book: hardcover, paperback, audiocassette. It also encodes nationality, so the ISBN for a given edition at www.amazon.com differs from the one at www.amazon.co.uk . This creates problems for All Consuming, which can't easily consolidate discussion about a given title, as well as for LibraryLookup, since the edition you're viewing in Amazon might not correspond to the one your library has.









