REST Content-Type: Should it be based on extension or Accept header?

Question

Should the representation(html, xml, json) returned by a RESTful web service be determined by the url or by the Accept HTTP header?

Answer 1

Both are valid. Quote from xml.com:

A resource may have more than one representation. There are four frequently used ways of delivering the correct resource representation to consumers:

1. Server-driven negotiation. The service provider determines the right representation from prior knowledge of its clients or uses the information provided in HTTP headers like Accept, Accept-Charset, Accept-Encoding, Accept-Language, and User-Agent. The drawback of this approach is that the server may not have the best knowledge about what a client really wants.
2. Client-driven negotiation. A client initiates a request to a server. The server returns a list of available of representations. The client then selects the representation it wants and sends a second request to the server. The drawback is that a client needs to send two requests.
3. Proxy-driven negotiation. A client initiates a request to a server through a proxy. The proxy passes the request to the server and obtains a list of representations. The proxy selects one representation according to preferences set by the client and returns the representation back to the client.
4. URI-specified representation. A client specifies the representation it wants in the URI query string.

Answer 2

This is a non-question.

Accept depends on conneg (content negotiation). Conneg will let the client decide what media type they accept through the Accept: header. The response will then be in that format, together with a Vary: Accept header.

On the other hand, it's also possible and perfectly valid to expose your resource as /resource.json and /resource.xml.

The ideal is to implement both: /resource (generic uri that supports conneg) /resource.xml /resource.json

the conneg'd version returned by /resource can simply redirect to the correct uri based on the negotiated media type. Alternatively, the correct representation can be returned from the generic uri, and use Content-Location to specify the sepcific representation that was returned.