That's interesting. That makes me think of all the times a frontend engineer has tried to get me to put display logic in backend APIs. Their arguments were: -

That's interesting. That makes me think of all the times a frontend engineer has tried to get me to put display logic in backend APIs. Their arguments were: - We can update the site without deploying code changes - These configurations can be actual configurations in our administration site, vs. code in the frontend - Dramatically simplifies the frontend My counterarguments were: - it doesn't make any sense to `GET /songs&limit=50&offset=1000` and also get ordering information or what have you, which changes the mental model from data store to application state store - we're not lowering complexity, we're just shifting presentation information to the backend where it certainly doesn't belong (imagine having to list songs in two different places that are presented differently--is that a different endpoint, a `scene` parameter, blah blah blah) - this information almost never changes But taken to its (I guess) logical conclusion here, where there's a sufficiently smart generic HATEOAS frontend, it's pretty cool? But I also guess it's not really different. Something has to know what order the buttons are in. If we're looking at the chain of a web stack, we have: [DB] -> [API] -> [Frontend] Doesn't it just seem like presentation stuff goes where we do the presenting? I think people's issue with HATEOAS is that we actually wanted an RPC backend where frontends control every aspect of the presentation, and HATEOAS wasn't just extra bloat, it put a straightjacket on design and asked backend engineers to start sending HTML again.