Justin Makeig <justin.makeig <at> troove.net> writes: > > It all depends on the Accept header that the client sends. For, > example Firefox (2.0.0.7) sends the Accept header: text/ > xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ > plain;q=0.8,image/png,*/*;q=0.5. This can be interpreted as > > text/xml: 100% > application/xml: 100% > application/xhtml+xml: 100% > image/png: 100% > text/html: 90% > text/plain: 80% > anything else (*/*): 50% > > where the percentages are "quality" determinations <http://www.w3.org/ > Protocols/rfc2616/rfc2616-sec14.html>--the higher the quality, the > more the client prefers it. As a result, if you declare that your > resource can be represented as both application/xml and text/html, > according to the above Accep header, you should be sending back XML. > I think Firefox is being forward-thinking with regard to XML and > XHTML, but not particularly practical here. (For example, IE cannot > handle pages served as application/xhtml+xml). (I don't have a > Windows machine in front of me, but I seem to remember that IE's > default Accept header is even less specific.) > > You can get around this several ways (some better than others): > > * using a client that allows custom headers (such as with an > XMLHttpRequest from within the browser) > * sniffing the requesting client and serving text/html to known browsers > * adding another request parameter to indicate the media-type, > overriding the accept headers (similar to RESTlet's support for > overriding the HTTP method to allow PUT) > > For browser clients I just lean toward always serving text/html (and > perhaps text/plain), no matter what the Accept header says. Clients > that really do care about the server being able to send back > resources based on the Accept header will most likely allow for > custom headers anyway (e.g. Accept: application/xml,application/ > json;q=0.9). > > Here's what Jerome had to say last November: <http:// > blog.noelios.com/2006/11/15/reconsidering-content-negotiation/>. > > I'd be interested in hearing others' takes, though. > > Justin
Justin, Thanks for the excellent description of how content negotiation works and the background on how browsers differ. That's very helpful. The blog post is confusing. It first says not to avoid content negotiation but goes on to propose a solution that avoids content negotiation by assigning unique URIs to each representation. We'd like to have a single resource and URI (GET http://host:port/service/foo) and return HTML if the client is a browser, and return something more machine friendly for a web service client. We use a lot of XML with JAXB and we have been specifying APPLICATION_XML for JAXB. It would be nice if there was some better (more distinguishing) media type for that. In a service I'm creating now, I'm looking at using JSON and that seems to avoid these problems to some extent. That's great for me, but other of our services pass complex data which benefits from JAXB. I'd also like to hear people's thoughts. Sean
