[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.