HATEOAS never gets the love it deserves until you call it something else..

Probably because it sounds like the most poorly named breakfast cereal ever.

MyOutfitIsVague 4 days ago | parent | next [-]

From a human user perspective, HATEOAS is effectively just the web. You follow links to get where you want, and forms let you send data where you want, all traversed from some root entrypoint.

From a machine client perspective, it's a different story. JSON-LD is more-or-less HATEOAS, and it works fine for ActivityPub. It's good when you want to talk to an endpoint that you know what data you want to get from it, but don't necessarily need to know the exact shape or URLs.

When you control both the server and client, HATEOAS extra pain for little to no benefit, especially when it's implemented poorly (ie. when the client still needs to know the exact shape of every endpoint anyway, and HATEOAS really just makes URLs opaque), and it interacts very badly when you need to parse the URL anyway, to pull parts from it or add query parameters.

▲

stronglikedan 3 days ago | parent | prev | next [-]

> HATEOAS ... sounds like the most poorly named breakfast cereal ever.

I think of flight stick controllers.

▲

cluckindan 4 days ago | parent | prev | next [-]

This has nothing to do with HATEOAS. Well, apart from both using URLs. But HATEOAS really isn’t about storing state in URLs.

	▲	naasking 3 days ago \| parent [-]
		> But HATEOAS really isn’t about storing state in URLs. I think saying they are unrelated isn't correct either. In order for hypermedia to be the engine of application state, the continuations of your application must be reified as URLs, ie. they must be stateful. This state could be stored server-side or in the URL, it doesn't matter, as URLs are only meaningful to the server that generated and interprets them.

▲

btown 4 days ago | parent | prev [-]

I mean, at the end of the day it is a cerealization format…

▲

cluckindan 4 days ago | parent [-]

Jokes aside, the crux of HATEOAS is having a dumb frontend which just displays content and links from backend responses. All logic is on the server side. It is more like a terminal connection than a browser based application.

	▲	tsimionescu 4 days ago \| parent [-]
		Not at all. HATEOAS is about defining data formats that the client and server agree on ahead of time. Browsers running Javascript referenced from HTML is a perfect example of HATEOAS, for example. browsers and web server creators agreed on the semantics of these two data formats, and now any browser in the world can talk to any web server in the world and display what was intended to be displayed to the user. If the web design hadn't been HATEOAS, you'd need server specific code in your browser, like AOL had a long time ago, where your browser would know how to look up specific parts of the AOL site and display them. This is also how most client apps are developed, since both the client and the server are controlled by the same entity, and there is no problem in hardcoding URLs in the client.