| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||
 COLUMN
The name game Over 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).
"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. There is arguably a need for an identifier that coalesces variant ISBNs. Amazon has, for example, a "See all editions" function that queries for a set of related editions. Suppose that Amazon wanted to offer an all-editions hook to partner applications. Does the fact that partners currently use edition-specific ISBNs preclude such a move? I don't think so. Both of the dominant Web servers include URL-rewriting engines. Apache's mod_rewrite is by far the most powerful and accessible. The ISAPI (Internet Server API) filter mechanism supported by Microsoft's IIS requires a lot more elbow grease. But in either case, it's feasible to support an old namespace in parallel with a new one. And you can be flexible about whether, and if so how, to migrate from one style to another. Amazon could support the new style by mapping it to the old one -- for example, by applying the rule that a generic identifier maps to the most recent or most popular edition. It wouldn't make sense to try to migrate Amazon users to the new style, because they must choose which edition to buy. But it would make sense to migrate All Consuming users to the new style, since book discussion is not edition-specific. In that case, an URL-rewriting engine could continue to support old-style links, but transform them to the new style. There's nothing new here. We've been playing this name game (often implicitly, to be sure) since the birth of the Web. Increasingly, we will find ourselves challenged to coordinate services. It's time to get explicit about the principles that inform our Web namespaces and the methods by which we manage them. 1. http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html 2. http://www.w3.org/DesignIssues/Axioms#opaque 3. http://groups.yahoo.com/group/rest-discuss/message/3232 4. http://groups.yahoo.com/group/rest-discuss/message/3237 5. http://groups.yahoo.com/group/rest-discuss/message/3241 6. http://www.allconsuming.net Jon Udell is lead analyst at the InfoWorld Test Center. Contact him at jon_udell@infoworld.com and check out his Weblog at http://weblog.infoworld.com/udell.  RELATED SUBJECTS  Web TechnologiesSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
