I'm working through designing a RESTful API.  We know we want to return JSON and XML for any given resource.  I had been thinking we would do something like this:GET /api/something?param1=value1Accept:  application/xml (or application/json)However, someone tossed out using extensions for this, like so:GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)What are the tradeoffs with these approaches?  Is it best to rely on the accept header when an extension isn't specified, but honor extensions when specified?  Is there a drawback to that approach?
REST - Tradeoffs between content negotiation via Accept header versus extensions
architecture;web services;rest;http
This, However, philosophically - the first approach is the only approach., and this The proper official RESTful approach is to use Accept: header. are widely perceived to be the case, but are also absolutely incorrect.Here's a brief snippet from Roy Fielding (who defined REST)...section 6.2.1 does not say that content negotiation should beused all the time. citeThat particular conversation is in the context of the 'Accept-Language:' header, but the same applies equally to the 'Accept:' header, as made clear later in his response...I have no idea why people can't seethe second and third link on the top pagehttp://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmthat point to the two PDF editions.What he means there is that there's no issue in using different endpoints for different representations of the same source data.  (In this case one .html endpoint and two different .pdf endpoints.)Also in a similar discussion, this time regarding the virtues of using query parameters vs. using file extensions for different media types...That's why I always prefer extensions.Neither choice has anything to do with REST. citeAgain, that's slightly different to Accept vs. filename extensions, but Fielding's stance is still clear.Answer - it really doesn't much matter.The trade-offs between the two aren't very significant and both are acceptable styles.