3 ms·

Where to start... First, nowadays altering the DOM is way more responsive than loading a new page, so no one really wants HATEOAS -- not even users, but especi

Where to start... First, nowadays altering the DOM is way more responsive than loading a new page, so no one really wants HATEOAS -- not even users, but especially not the sites we like to visit because they don't want to put out public APIs anymore. For non-browser app APIs (public or private), well, they can be the same, just driven by JS when in-browser. This... is sad. But this is a fact of life now. Just watch Tom Scott explain why the APIs went away, and when the APIs went away, so did HATEOAS (https://www.youtube.com/watch?v=BxV14h0kFs0 https://www.youtube.com/watch?v=BxV14h0kFs0). Second, there's a lot of APIs that needn't have anything more than one end-point -- no links to traverse, no HATEOAS. For example, a certification authority can take a CSR and authentication and return you a certificate -- one end-point is all you need, and other than that, the API can be RESTful in every sense. And then there's APIs where links aren't necessarily abundant or interesting. Third, HTTP kinda sucks anyways if you're dealing with databases. There's no nice RESTful way to construct transactions unless you put the RDBMS smarts into the client (JS again), which you can't do if it means trusting the client (it does). So right there, REST is broken anyways. Sure, if you're distributing your database, you need to deconstruct your transactions anyways, but you're not going to trust a user-agent to get that right, and anyways, you can't really do that with a HATEOAS interface. Put another way: show us how to build a secure application with REST (including HATEOAS) that a) users will enjoy, b) companies want to build, c) with complex transactions. If you do, we might all get our pitchforks out and protest for HATEOAS. Searching for examples of HATEOAS, I don't find much. Sure, for proprietary, corporate apps HATEOAS can be meaningful, but even there, I suspect for devs it's easier to just define APIs and drive all in-browser interaction via JS.

rumanator 6y ago
None of your points make any sense. It's as if you believe HATEOAS is something entirely different than what it really is. The DOM is irrelevant wrt HATEOAS. HATEOAS is just a way to decouple clients from servers. You get that by not resorting to hardcoded links, and instead getting your server to supply links to clients in the form of links driven by link relations. HATEOAS is capabilities discovery. HATEOAS is API versioning without explicit versions. HATEOAS is a documented and discoverable API. That's it. It's also irrelevant to HATEOAS if you have 1 our 9999 links. You set a root document with a link. That's it. HTTP is completely irrelevant to HATEOAS. HATEOAS is an element of an architecture style. You can do REST with UDP if you'd like. And no, you can easily do transactions with REST over HTTP. No need to mix DB stuff on the API. Finally, you let it clear that you don't like REST or HATEOAS. That's ok. Yet, your personal preferences don't mean something is broken, specially if they are derived from misconceptions, confusion and ignorance.
- gridlockd 6y ago
  Manipulating the DOM is not irrelevant in the sense that pretty much the only way HATEOAS could be useful is in generating a user interface that an intelligent agent could navigate. Only an intelligent agent could meaningfully navigate from one state to another, which is roughly equivalent to a clicking on URLs on static sites, which is how most websites work or at least used to work. When you manipulate the DOM to implement interaction without any "hypermedia links", there is an impedance mismatch here and HATEOAS is not a good choice for user interfaces anymore. > HATEOAS is capabilities discovery. HATEOAS is API versioning without explicit versions. HATEOAS is a documented and discoverable API. That's it. You can't discover capabilities without prior knowledge unless you are an intelligent agent. That's why HATEOAS is a really bad choice for APIs. You effectively have to implement the agent "discovering" what you expect to be there, instead of just explicitly asking for what you need. It's not just pointless, it's a waste of time.
  - cryptonector 6y ago
    Exactly. Thank you for putting it so well.
  - rumanator 6y ago
    > Manipulating the DOM is not irrelevant in the sense that pretty much the only way HATEOAS could be useful is in generating a user interface that an intelligent agent could navigate. That's patently wrong, and ignores basic RESTful standards such as HAL. The DOM is irrelevant and meaningless in the context of HATEOAS. There is no DOM at all. There is a resource, and the resource is tagged with link relations. That's it. Just because the word Hypermedia" pops out this does not mean HATEOAD has anything to do with HTML. > Only an intelligent agent could meaningfully navigate from one state to another, which is roughly equivalent to a clicking on URLs on static sites, which is how most websites work or at least used to work. This is where you're objectively showing where you're getting it wrong. REST I'd about resources and resources representations. Your "URL" is just a specific resource, and that resource is tagged with link relations which point to to other resources. It's the resource that is linked, not the content of the resource. > When you manipulate the DOM to implement interaction without any "hypermedia links", Again, you're showing where you've been getting it wrong. You do not manipulate any DOM to "implement interactions". You just get the link relations of a resource. That is all. Some HATEOAS formats even pass link relations through HTTP headers. The concept of a DOM is entirely meaningless in REST. There are only resources, resource representations, and link relations. That's it. Again, just because HATEOAS has "hypermedia" in its name that does not mean it has anything to do with HTML.

rumanator 6y ago

None of your points make any sense. It's as if you believe HATEOAS is something entirely different than what it really is. The DOM is irrelevant wrt HATEOAS. HATEOAS is just a way to decouple clients from servers. You get that by not resorting to hardcoded links, and instead getting your server to supply links to clients in the form of links driven by link relations. HATEOAS is capabilities discovery. HATEOAS is API versioning without explicit versions. HATEOAS is a documented and discoverable API. That's it. It's also irrelevant to HATEOAS if you have 1 our 9999 links. You set a root document with a link. That's it. HTTP is completely irrelevant to HATEOAS. HATEOAS is an element of an architecture style. You can do REST with UDP if you'd like. And no, you can easily do transactions with REST over HTTP. No need to mix DB stuff on the API. Finally, you let it clear that you don't like REST or HATEOAS. That's ok. Yet, your personal preferences don't mean something is broken, specially if they are derived from misconceptions, confusion and ignorance.

gridlockd 6y ago
Manipulating the DOM is not irrelevant in the sense that pretty much the only way HATEOAS could be useful is in generating a user interface that an intelligent agent could navigate. Only an intelligent agent could meaningfully navigate from one state to another, which is roughly equivalent to a clicking on URLs on static sites, which is how most websites work or at least used to work. When you manipulate the DOM to implement interaction without any "hypermedia links", there is an impedance mismatch here and HATEOAS is not a good choice for user interfaces anymore. > HATEOAS is capabilities discovery. HATEOAS is API versioning without explicit versions. HATEOAS is a documented and discoverable API. That's it. You can't discover capabilities without prior knowledge unless you are an intelligent agent. That's why HATEOAS is a really bad choice for APIs. You effectively have to implement the agent "discovering" what you expect to be there, instead of just explicitly asking for what you need. It's not just pointless, it's a waste of time.
- cryptonector 6y ago
  Exactly. Thank you for putting it so well.
- rumanator 6y ago
  > Manipulating the DOM is not irrelevant in the sense that pretty much the only way HATEOAS could be useful is in generating a user interface that an intelligent agent could navigate. That's patently wrong, and ignores basic RESTful standards such as HAL. The DOM is irrelevant and meaningless in the context of HATEOAS. There is no DOM at all. There is a resource, and the resource is tagged with link relations. That's it. Just because the word Hypermedia" pops out this does not mean HATEOAD has anything to do with HTML. > Only an intelligent agent could meaningfully navigate from one state to another, which is roughly equivalent to a clicking on URLs on static sites, which is how most websites work or at least used to work. This is where you're objectively showing where you're getting it wrong. REST I'd about resources and resources representations. Your "URL" is just a specific resource, and that resource is tagged with link relations which point to to other resources. It's the resource that is linked, not the content of the resource. > When you manipulate the DOM to implement interaction without any "hypermedia links", Again, you're showing where you've been getting it wrong. You do not manipulate any DOM to "implement interactions". You just get the link relations of a resource. That is all. Some HATEOAS formats even pass link relations through HTTP headers. The concept of a DOM is entirely meaningless in REST. There are only resources, resource representations, and link relations. That's it. Again, just because HATEOAS has "hypermedia" in its name that does not mean it has anything to do with HTML.