[osigurdson]

It isn't clear that HATEOS would be better. For instance:

>>Clients shouldn’t assume or hardcode paths like /users/123/posts

Is it really net better to return something like the following just so you can change the url structure.

"_links": { "posts": { "href": "/users/123/posts" }, }

I mean, so what? We've create some indirection so that the url can change (e.g. "/u/123/posts").

[rswail]

Yes, so the link doesn't have to be relative to the current host. If you move user posts to another server, the href changes, nothing else does.

If suddenly a bug is found that lets people iterate through users that aren't them, you can encrypt the url, but nothing else changes.

The bane of the life of backend developers is frontend developers that do dumb "URL construction" which assumes that the URL format never changes.

It's brittle and will break some time in the future.

[osigurdson]

>> If you move user posts to another server, the href changes, nothing else does

It isn't clear what insurance you are really buying here. You can't possibly mean another physical server. Obviously that happens all the time with any site but no one is changing links to point to the actual hardware - just use a normal load balancer. Is it domain name change insurance? That doesn't add up either.

>> If suddenly a bug is found that lets people iterate through users that aren't them, you can encrypt the url, but nothing else changes.

Normally you would just fix the problem instead of doing weird application level encryption stuff.

>> The bane of the life of backend developers is frontend developers that do dumb "URL construction" which assumes that the URL format never changes

If those "frontend" developers are paying customers as in the case of AWS, OpenAI, Anthropic then you probably want to make your API as simple as possible for them to understand.