What are the Pros and Cons of using URI vs Accept Headers for REST content format negotiation?

Based on info in the following question REST Content-Type: Should it be based on exten开发者_JS百科sion or Accept header?, I'm aware either custom URIs or specifying Accept Headers are 'acceptable' (pun intended) methods for for a REST-ish web service to determine response format for the client.

However, a lot of big names seem to use the custom URI method with their APIs. What are the strengths of one way over the other?

In REST, URIs are intended to identify only a resource. Content negotiation is used to identify representation format. It's your traditional separation of concerns. When using the URI to identify the representation format you are mixing those concerns.

In addition to mixing concerns, my observation is that when using the URI based approach people generally know the convention and rely on URI building rather than hypertext to navigate. This increases coupling and can cause problems if the server ever wants to change the URI structure.

With that being said, there are some positives from the URI approach, namely convenience. During development, you can launch the browser and easily see what the server is responding with by simply entering it in the address bar ('example.com/foo.json'). When relying 100% on content negotiation it's a bit more difficult, and you have to rely on plugins or cURL, anything that can manipulate the headers.