> What's the actual point, other than some purity to some abstract concept?
The actual point is decoupling. It's generally considered in software architecture that design that's decoupled is a little harder to build upfront, but survives change over time.
As a 'real life' example, because Twitter exposed internal details (a tweet ID), clients sorted based on that number, because they assumed it'd be monotonically increasing. Once sequential IDs became a problem with Twitter at scale, they had an issue: if they switched to GUIDs, clients would break, because they were sorting based on the ID value. They had to invent an entirely new algorithm (Snowflake) to adapt to this change. This wouldn't have happened if they hadn't leaked internal details. It's basic encapsulation.
I'm not sure how the Twitter example is remotely related to what I'm asking. You're saying that if Twitter returned long URLs as opaque tokens to get, then it'd have been ok. Sure, but it'd have been fine if they had made the tweet id an opaque token either way. Surely returning named URL pairs isn't "basic encapsulation", and "GET /Tweet/<token>" has no reason to break.
I can see how returning hypermedia adds yet another layer of abstraction (and potentially plenty more round trips!). I'm just unsure how it helps. I don't understand how actual client code (besides a browser) can deal with arbitrary hypermedia. I'm cautious when I don't understand why people are hyped up about something, but I've yet to see any "real life" examples that demonstrate real benefits of this approach.
I can't point to them because they're internal, but there are some good ones I've used. Pagination was one useful part, where we saw the API change but didn't have to change the client. A second was being able to explore parent relationships, so we could start somewhere in the tree and move up until we hit the level we were interested in.
There are always agreements between the API designers and client designers, because the code isn't intelligent, so it doesn't know what 'parent' means. If the name of that changes, then the client would have to change. What can be different is the url structure to get the 'parent'. Maybe there's a new token that has to be there, or the naming of something has been changed, or whatever. Those changes can be made without breaking the clients. Putting this in the responses means two things:
1) Small changes don't break everything (pagination is a great one, its a /pages/1 one day then ?page=1, then ?offset=25, then ?pageSize is optional, then it's required, etc.).
2) Fewer assumptions baked into the client. Getting the tweets for a user you've loaded would be nicer as load(user.tweets) than load("/tweets/"+user.id)
The actual point is decoupling. It's generally considered in software architecture that design that's decoupled is a little harder to build upfront, but survives change over time.
As a 'real life' example, because Twitter exposed internal details (a tweet ID), clients sorted based on that number, because they assumed it'd be monotonically increasing. Once sequential IDs became a problem with Twitter at scale, they had an issue: if they switched to GUIDs, clients would break, because they were sorting based on the ID value. They had to invent an entirely new algorithm (Snowflake) to adapt to this change. This wouldn't have happened if they hadn't leaked internal details. It's basic encapsulation.