4 ms·

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. H

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.
  - cryptonector 6y ago
    The way you debate won't make you friends. When you attack the way you do, the other side just discounts what you have to say. There's a better way to do this. > This is where you're objectively showing where you're getting it wrong. [...] The text I elided in that quote says nothing about how GP is wrong. Saying "objectively" doesn't make it so. You have to back up your arguments. In a way you're quite right: links don't have to be URIs, hypermedia doesn't have to be HTML, and links don't even have to appear in the media when you can construct them algorithmically (in the last case you can argue that even though they are absent in the media, they are notionally still there). However, GP is right that only an intelligent agent will be able to use useful things with links of types they don't already have baked in logic for doing things with, and this is really the key problem with HATEOAS: it's too human-centered, and implicitly so. Anyways, be kind.
cryptonector 6y ago
I only don't like HATEOAS. The rest of REST is fine, well, except for the transaction problem, but we all make do. The DOM thing was answered ably by u/gridlockd separately, so I won't say much more about it other than this: in a modern web app you won't necessarily see links in the resources fetched by JS -- you might need to know how to transform that content into links (if there are any), and you might find that embedded as logic in the JS. That's not really HATEOAS unless it's documented and stable.
- rumanator 6y ago
  > I only don't like HATEOAS. The rest of REST is fine, There is no "rest of REST" once you omit HATEOAS. That assertion makes absolutely no sense. HATEOAS is the whole basis of REST. If you take HATEOAS away, all you get is plain old RPC. > The DOM thing was answered ably by u/gridlockd That response is packed with errors and misconceptions. Instead of paying attention to echos of your errors you would do better to discover what REST and HATEOAS actually is, because both of you have repeatedly shown that your grasp on the subject needs a lot of work to iron out a lot of basic misconceptions. > in a modern web app you won't necessarily see links in the resources fetched by JS -- you might need to know how to transform that content into links (if there are any), That is the sort of comment that makes it quite clear that you have no idea of what you're talking about. Resources and resources representations are not platform-dependent or even format-dependent. REST is not making a fetch(), and HATEOAS is not a HTML document with <a> tags. REST is an architecture style defined by HATEOAS. It doesn't care about HTTP or TCP or even IP. It cares about resources and resources representations, and cares about link relations associated with resources. What you decide to do with JavaScript is irrelevant. The only thing that matters is what are your resources and where are the link relations, and HTML or JavaScript plays no role in any of the concepts.

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.
- cryptonector 6y ago
  The way you debate won't make you friends. When you attack the way you do, the other side just discounts what you have to say. There's a better way to do this. > This is where you're objectively showing where you're getting it wrong. [...] The text I elided in that quote says nothing about how GP is wrong. Saying "objectively" doesn't make it so. You have to back up your arguments. In a way you're quite right: links don't have to be URIs, hypermedia doesn't have to be HTML, and links don't even have to appear in the media when you can construct them algorithmically (in the last case you can argue that even though they are absent in the media, they are notionally still there). However, GP is right that only an intelligent agent will be able to use useful things with links of types they don't already have baked in logic for doing things with, and this is really the key problem with HATEOAS: it's too human-centered, and implicitly so. Anyways, be kind.

cryptonector 6y ago

I only don't like HATEOAS. The rest of REST is fine, well, except for the transaction problem, but we all make do. The DOM thing was answered ably by u/gridlockd separately, so I won't say much more about it other than this: in a modern web app you won't necessarily see links in the resources fetched by JS -- you might need to know how to transform that content into links (if there are any), and you might find that embedded as logic in the JS. That's not really HATEOAS unless it's documented and stable.

rumanator 6y ago
> I only don't like HATEOAS. The rest of REST is fine, There is no "rest of REST" once you omit HATEOAS. That assertion makes absolutely no sense. HATEOAS is the whole basis of REST. If you take HATEOAS away, all you get is plain old RPC. > The DOM thing was answered ably by u/gridlockd That response is packed with errors and misconceptions. Instead of paying attention to echos of your errors you would do better to discover what REST and HATEOAS actually is, because both of you have repeatedly shown that your grasp on the subject needs a lot of work to iron out a lot of basic misconceptions. > in a modern web app you won't necessarily see links in the resources fetched by JS -- you might need to know how to transform that content into links (if there are any), That is the sort of comment that makes it quite clear that you have no idea of what you're talking about. Resources and resources representations are not platform-dependent or even format-dependent. REST is not making a fetch(), and HATEOAS is not a HTML document with <a> tags. REST is an architecture style defined by HATEOAS. It doesn't care about HTTP or TCP or even IP. It cares about resources and resources representations, and cares about link relations associated with resources. What you decide to do with JavaScript is irrelevant. The only thing that matters is what are your resources and where are the link relations, and HTML or JavaScript plays no role in any of the concepts.