Blog

Reconsidering content negotiation

November 15, 2006

Posted by Jerome Louvel in : Restlet General

Content negotiation (or conneg) is a powerful but vastly underused feature of HTTP. In the past, its usage was difficult due to the limitations of browsers and the lack of flexible support from server frameworks.

Back in 2003, Joe Gregorio concluded that this feature was creating too many problems to be considered for Web Services. Norman Walsh also had a pretty negative experience with it on his web site.

These blog posts point to some real issues, but none of them is really blocking or should lead people to bypass content negotiation completely. Let’s review the concerns and see how we can provide satisfying solutions using the Restlet framework which full support for this feature:

1) How can the browser influence the servers choice to get something it can handle?

First, if you give a separate URI to each representation, it’s very easy to explicitly request one representation instead of relying on content negotiation.

Also, the server can provide mechanisms to easily change the value of the Accept header. With Restlets, each Application has a default TunnelService configured that can override the value in the Accept headers by using query parameters (“language”, “media”, “charset”, “encoding” and also “method”). Also, the Directory Restlet that serves static files understand the file extensions when doing conneg.

If you have file.txt, file.pdf, file.html in your directory, you can either use a neutral URI like http://example.com/mydir/file or more explicit one like http://example.com/mydir/file.pdf if you want a precise representation.

2) How does the server know which representation to serve?

The fact that clients or servers can be misconfigured is not a solid reason to bypass conneg IMO. Many things can be misconfigured (authorizations) and yet no one thinks about not using the feature.

Using the solution proposed in 1), the other arguments made by Joe are not valid anymore. Finally, it is important that all those issues only occur with browsers. If you invoke your web services using other type of clients (Apache HTTP Client, HttpUrlConnection, Curl, etc.) you generally have full control on the Accept* headers.

Note that last year, Joe Gregorio wrote an interesting column in XML.com explaining how to parse the Accept headers, with sample Python code. In the Restlet engine we have some similar logic too that you can benefit from by simply using a client preference model.


Recent Posts



comments powered by Disqus