Earthly Powers

RESTful Web Services book and conneg

Update 01/06/07:  Leonard provides some more info.

Update 30/05/07:  After reading some further chapters (perhaps i should keep my mouth shut until i finish :-) ) the distinct URI is really only advocated for the media type and/or the language such as:

http://www.example.com/releases/104.xml.en

which makes more sense.

I am about half way through the RESTful Web services book by Leonard and Sam. So far the book has been an enjoyable read and i like the prescriptive approach (similar to that taken by Joe) to designing RESTful services.

The only area that i am not sure i agree with is the recommendation of the technique to give a distinct URI to each representation of a resource in addition to using the 'platonic' URI. Presumably if you can negotiate the content type, the charset, the encoding and the language one might end up with a distinct URI like the following:

http://www.example.com/releases/104.xml.en.gzip.UTF-8

When returning a representation with links to other resources what URIs should be used for those links? Distinct URIs, if so which ones? Or should one use the 'platonic' URIs instead and the client infer what the distinct URIs are?

The W3C HTML validator was cited as an example of where it is not possible to manage language thus it is necessary to expose all URIs as distinct URIs for the language. Perhaps it would be easier to fix the validator to use Accept-Langauge by supporting an additional query parameter rather than all clients requiring distinct URIs. Is it really that hard to fix?

Browsers could adjust the Accept header when getting an alternate link, according the type attribute declared in an HTML link tag. A browser like Firefox knows that an HTML page may also have an Atom feed (because the type of the link is 'application/atom+xml') but when the alternative link is obtained Firefox does not adjust the Accept header so that 'application/atom+xml' is the most acceptable. This precludes using the same URI for HTML and Atom. Is it really that hard to fix?

Part of the problem is that it is not possible to query a resource for its content capabilities (multiple HEAD requests are rather inefficient, the HTTP method OPTIONS is under utilized, perhaps a quick hack for such a method is to return an HTML document consisting of a head tag, with alternative links, and no body?? or even better a WADL document). But i can't help thinking that if clients (browsers) and services were just a little bit more savvy with content negotiation such workarounds (is it an anti-pattern?) would not be needed as much and thus conventions for distinct URIs would not get sedimented into frameworks like RoR.

Posted at 10:47AM May 29, 2007 by Paul Sandoz in REST  |  Comments[3]