For me, the 2 things that set off my bullshit detector about HATEOAS are these:

1. Everybody who buys into it, including Roy Fielding himself, has to constantly say "no, that's not what I meant" and "you're not doing it right" if a REST service doesn't use HATEOAS. It reminds me of the response you get when you point out to college kids how bad Communism works out in the real world (see USSR, North Korea, et al): "No no no, it could really work, just nobody has done it right yet"

and 2: All the arguments eventually come back to an Appeal to Authority. "Well, Roy Fielding's dissertation says...". I sense that the real argument eventually comes down to whether a service can be called RESTful according to Fielding's dissertation, vs whether or not HATEOAS is actually a good idea.

I use HATEOAS because I derive very specific benefits from the client/server decoupling it enables. I have used it to build a large business application. I agree that far too many people talk about HATEOAS that have never really used it on real projects and that is unfortunate. However, I suggest you avoid throwing out the concept because the messengers are inadequ

With the exception of spiders and other AI-like things, no, we are not expecting clients to spontaneously consume RESTful services in meaningful ways. REST clients are generic. They don't know anthing about specific services, thus allowing those services to evolve independently. A client that is coupled to a specific service is not RESTful, nor is any API that can only be consumed by such a client.

You comment is correct, despite the downvotes. The hypermedia isn't there so AI or spiders can navigate, it is there to reduce coupling.

--

A Rant follows. Disclaimer: I'm not an expert on the subject so feel free to correct me or anything.

The WWW itself is "RESTful". Even Hacker News is RESTful. You don't care about the URLs that show in your address bar. You don't construct them based on an ID-number on the side of each post. You just click around and submit forms.

With hypermedia, your consumer doesn't need to know about those specifics of URL construction. URLs are transparent. You just query for Resources and follow links.

YES, absolutely ZERO coupling is MUCH easier with boring CRUD-like stuff, such as Microsoft's OData, GData or AtomPub.

Maybe when you're writing a good consumer tuned for usability (like a Twitter client) you, app builder, will need to know some details on the service beforehand, but even then, having hypermedia would be cool. With a nice and pretty RESTful API, Twitter could just roll out new features, such as 'people who recently retweeted you' and you'd have a new section show up on your app instantly, since it discovers resources. Maybe you could even, like, load icons for new sections via links on the API itself...

Another example: I used to work on an App that used hypermedia: an Enterprise Content Manager with an OData API. Enterprise people used an decoupled enterprise client called Excel to connect to our Enterprise server and build random reports themselves.

So say you want to get data from a RESTful web api, do you have to customize your generic REST client? Because everything I've ever written that called an external API had to know what it was looking for in advance. Like to interact with Twitter's API, I went to their documentation page and read up on what URL's to call for the information I needed.

If you want a client coupled to a specific service then you don't want REST, you want a classic client-server architecture, which is more or less the antithesis of REST. But everyone insists on calling it REST when it goes over HTTP, then they complain that the apple tastes nothing like an orange.