"HTTP Accept headers (and indeed, use of many fancy headers) are beyond what most client developers will bother with; including the response format in the URL with a ".xml" or ".json" is natural and obvious."
That was in a comment by Alex Payne [1] near the bottom. Obviously it's been quite a few years since he wrote that but it's what I personally think, too. The extent that many blog articles and comments take REST really adds far too much complication. Are client-side developers going to understand how to use your API? Always keep your target market in mind.
Honestly in my mind that's the most important point to take from this article.
Of course we have to be pragmatic about these things - if you have a business that will live or die based on the success or failure of its API then you have to make your decision based on that - but there are times that it makes sense to push the boundaries of what developers are comfortable with, yes? Otherwise how do we expect things to progress?
Putting the format in the URL itself is much easier than having to fiddle with HTTP headers. Not to mention the ability to view API data directly within the browser is a major advantage in discoverability.
Using accept headers and browser discoverability do not have to be mutually exclusive. You can recognize browsers based on user agent and relax the requirements on accept headers.
That was in a comment by Alex Payne [1] near the bottom. Obviously it's been quite a few years since he wrote that but it's what I personally think, too. The extent that many blog articles and comments take REST really adds far too much complication. Are client-side developers going to understand how to use your API? Always keep your target market in mind.
Honestly in my mind that's the most important point to take from this article.
[1] http://al3x.net/about.html