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:

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:

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.


By "Joe" are you referring to Joe Gregorio? If so, check out what he has to say on this subject.

Posted by Sam Ruby on May 29, 2007 at 01:50 PM CEST #

I agree with Joe that content negotiation today is broken. But that's not a reason to avoid it completely. The only reason it's broken is because servers and clients in particular, are broken. If the awareness of the 'Accept' header raises and it can be used as an input in more and more online services (like the W3C Validator) and web browsers, it can ultimately lead to content negotiation not being broken anymore. I do see a problem with conneg still, though. It applies mainly to web browsers, which accepts basically most content types being served on the web. The problems with web browsers is that there's no good way for them to set a preference for the content types it accepts. Should it prefer XHTML over HTML? XML over XHTML? PDF over DOC? PNG over GIF or JPEG? How should it know? Conneg can work fine in more isolated cases, though, where it's clearer which content type to choose, both for the client and for the server.

Posted by Asbjørn Ulsberg on May 30, 2007 at 03:04 AM CEST #

Sam, yes the Joe i was referring was the (one and only?) Joe Gregorio.

Thanks for the informative link, it led to Norm Walsh's experiences with conneg and then to Jerome Louvel's ideas.

I understand better the motivation for recommending distinct URIs, which i think is about a service exposing predictable behaviour in the face of 'broken' clients/services (a pragmatic reason) or because sometimes URIs are consumed in other contexts where the meta-data cannot be exchanged or is not known (an 'engineer for serendipity' reason).

Posted by Paul Sandoz on May 30, 2007 at 11:29 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016