Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Based on info in the following question REST Content-Type: Should it be based on extension 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.