[hbrn]

No, there's illusion of value:

1. Paths are changed extremely rarely. Optimizing architecture for something that happens once a year is not a good idea. The cost of changing paths manually is pretty much always lower than the cost of HATEOAS.

2. You still want redirects from the old paths, because clients keep old paths in memory until refresh (which you don't control).

3. Typically when paths are changed, it also affects the entry point, so client still needs to be updated.

[schnable]

It depends on your use case. I have resolved critical bugs for mobile apps quickly server side using HATEOS by doing things that sticking extra parameters on a URL or rerouting traffic. The alternative would be updating multiple clients, QAing them, and getting them through app store reviews. If the clients aren't within your control even that isn't possible.

[hbrn]

Sure, HATEOAS can be useful when you don't have control over clients or over the routes.

Which is exactly the case for WWW: clients are browsers (not developed by you), and URLs can be images from another server (not owned by you).

And while it can happen for APIs, those cases are exception rather than the rule. That's why it's so annoying when REST purists are trying to shame people who are actually doing the right thing.

I would also be curious to learn how exactly sticking extra params would fix a critical bug. I can't help but wonder if bugs were caused by HATEOAS in the first place.