Hacker News Reader

Hacker News

Comment by querulous | Hacker News Reader

Parent Full thread

querulous

every web browser you use is a hateoas client

you get some html with embedded links and then the browser automatically goes and fetches css, js, images...

the remaining links it just presents to you, the user, to follow or not as you choose

hateoas is not a complicated idea. it's not meant to replace SOAP or gRPC or thrift. it's something else

View on HN

Except the browser really isn't. It has strict behavior, and the list of what happens as it loads that hypermedia is deterministic and known to both the client and server. The difference between what happens when the browser sees a "stylesheet" link reference and a "icon" one is significant, and not something the browser is expected to figure out on its own.

The HATEOAS idea is that you throw that out, just use some aribitrary XML (sorry, "hypermedia") to return your application state, and that this somehow magically empowers the client to be able to puzzle out all the things that can be done to your state.

Except it can't. It's just arbitrary junk if you don't have a schema and a spec. And it will always be so. Discoverability is (1) not something you can get from a data structure and (2) something best provided by documentation, not runtime behavior.

You obviously need SOME spec or schema to be able to understand what to do with hypermedia, but it really comes down to how many things you have to define. It lets you define a smaller number of pieces and their functionality, and then lets you compose those smaller pieces into larger functions, and even create new combinations after a client is created without having to update the client.

I think you have a completely wrong idea about HATEOAS. The application is certainly expected to be able to handle the data format, not figure out by magic. As Fielding writes in his dissertation, REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types. The client is certainly supposed to understand these data types, that's why they must be standard (like HTML). The dynamic part comes from the formats themselves, which may have variable or optional elements depending on the state of the resource.

Someone needs to fix the wikipedia page on HATEOAS then, because it says exactly the opposite of what you just did in its third sentence.

(One of the other problems with Fielding's work is precisely this word-salad of new jargon and usages, leading to exactly this kind of what-does-it-REALLY-mean-anyway confusion. But that's an argument for a different thread.)

From the wikipedia page: "The media types used for these representations, and the link relations they may contain, are standardized."

As for Fielding's work having a word-salad of new jargon and uses, I frankly didn't get that by reading his dissertation, which I found quite clear. There are a few concepts (Resources, Representations), but I think they make sense in the context.

The browser is driven by advanced AI wetware that understands the semantics of the data and can make decisions on what to do next.

I think REST/HATEOAS purists have always overplayed the browser example.

Pure machine to machine interaction is hard to automate.

You can use game AI techniques like needs-based-AI to create smart, resilient clients. What fun!

Reply on news.ycombinator.com