Edit: (to the downvoter) this post explicitly mentioned "You get clean exception handling via HTTP status codes". The exception handling may be clean, but it's extremely coarse.
I designed a REST API that's primarily (well, currently only) used for mobile applications, and it was often hard to decide whether to “denormalize“ the API (fewer API calls required, but more data per call) or provide very general fine-grained resources.
"It’s expressive, REST paths and CRUD requests are easy to understand _and hypermedia makes it easy to navigate_"
It's that second part that so many implementations gloss completely over, it's probably worth discussing that separately in the same way that authentication is discussed in the post.
As an example, 90+% of the web APIs I've designed and worked with are heavily used by mobile clients, which often suffer low bandwidth and high latency. Using proper HATEOAS URIs bloats payloads. Similarly, high latency for requests means that traversing hypermedia links across the API space is untenable.
In the real world, we design a structured API with well-known endpoints, and clients directly retrieve the resources they need. If the API needs to diverge from the specification substantially, then it gets versioned. The result is small, simple JSON payloads and nice, responsive clients.
If I'm missing something obvious here, I'd love to be educated.
The website example below is a good one, but as I'm and infrastructure oriented kind of guy I'll give another one which is the Sun Cloud API, under the now defunct project Kenai http://kenai.com/projects/suncloudapis/pages/Home. For example, doing a GET on a VM resource will return a payload that contains a URI for a power operation on the VM. What that power operation is obviously depends on what the power state of the VM at the time of the GET. The AWS API's provide a SOAPy interface, but they return information about objects that much more adheres to HATEOAS than the Rackspace API for example, which goes to _great_ lengths to espouse it's RESTy virtues (even consisently, and incorrectly, lowering the 'E' in the API docs lol).
So yeh, of course it all comes down to the infinite scales of grey, I wasn't trying to imply that I know any better than anyone or that REST-without-HATEOAS is wrong or suboptimal or whatever (and I know you're not interpreting it that way either), just that I have sometimes wondered how many REST implementors actually took the time to understand what Fielding was/is on about. And I certainly don't believe you or the author of the post fall into that category!
As other commenters, and Fielding himself, have pointed out, REST is inefficient in terms of both computer and human resources. It's an architecture optimized for wide scale and long term use. That's why most APIs don't turn out very RESTful.
I think it would be kind of cool to have a little project/developer toy that would be an API where only a single endpoint was provided (think http://mysteryapi.com), and the rest of it had to be discovered. It could be like the labyrinth from House of Leaves, but in REST API format.
http://ws-rest.org/2010/files/WSREST2010-Preliminary-Proceed... starts at page 6
About the best example I can think of is the Atom publishing protocol where a service links to it's publishing URLs and a feed can provide pagination through hyperlinks. But still it is not a particularly sophisticated example, do you know of any others?
If you can implement your service entirely with existing formats, that could make things much simpler. But the only kind of hypermedia for machine data access that I've ever heard of is RDF, and there is nothing simple about that.
There are many hypermedia formats built on XML, but when it's just used as a data container for an API, it's not hypermedia.
A key point is this paragraph:
"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]"
When I try to absorb this and other points in that blog entry, I feel like I've failed to understand the real lessons and I'm thinking too short-term with fixed URIs for CRUD on data. But then again, in the comments, Fielding says "REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency."
This makes a lot of sense to me and suggests that truly RESTful design isn't necessarily the best fit for people who want to throw stuff up on the web and then evolve to a more stable API.
If the server can evolve new functions independent of the client then it seems to me that the client has to evolve new intentions independent of the server. At present, clients can only do that with a human operator.