HATEOAS-y design gives you a great deal of flexibility in how you structure your server side without that complexity bleeding into to the client. E.g., by usin

HATEOAS-y design gives you a great deal of flexibility in how you structure your server side without that complexity bleeding into to the client. E.g., by using full URLs throughout your API, your client doesn't need to care whether it's getting info from "http://example.org/item/23" http://example.org/item/23" or "https://cdn.example.com/aonteuh/d81c7d65-1352-48f0-97fd-dc1c80c437d5.json?logid=user5" https://cdn.example.com/aonteuh/d81c7d65-1352-48f0-97fd-dc1c... Imagine if image tags in HTML were just "<img imgid='23'>" and the browser knew to look them up at "http://example.org/images/23" http://example.org/images/23". You could make a functioning web site with that, but it would limit the things you could do, and maybe even the way you thought about linking. That being said, there are almost always things you can do "better" by constructing the URLs in the client, like reducing response size, and fetching multiple items in a request. It's a trade-off, and I'd be wary of a 'REST enthusiast' who didn't acknowledge that. It could mean that they don't have enough real-world experience to have encountered the rough spots.