5 ms·

As someone who once bought into the entire HATEOAS thing, and wrote a (somewhat widely used) python library[0] for interacting with HAL+JSON apis, let me be the

As someone who once bought into the entire HATEOAS thing, and wrote a (somewhat widely used) python library[0] for interacting with HAL+JSON apis, let me be the first to say: Let it die. HATEOAS doesn't solve any problems that we actually have. GraphQL is something that solves the problems we actually have with JSON APIs. Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. If you try to remove hard-coding from your API and make it all navigable by some generic client, you end up just building abstractions and generality that's never needed by anyone. It'll waste a lot of time, and make your frontend developers hate you. Please, let HATEOAS die and let's never mention it again. Thanks [0]: https://rest-navigator.readthedocs.io https://rest-navigator.readthedocs.io

Groxx 4y ago
>Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. Yeah, once I realized this, HATEOAS / "strict" REST immediately went into my "nope" bucket. It's pretty much fine for humans and makes some compelling decisions in that context, but it's wildly unusable and unstructured for literally anything else and that makes it almost useless. HTTP verbs and codes are plenty useful, and REST has been co-opted to mean "use verbs and codes correctly" and... I'm OK with that. It summarizes as "follow the patterns that much of the computing world relies on, so you don't break shit everywhere all the time" and that's something absolutely worth understanding and adopting in depth.
hudon 4y ago
I don’t know if you’ve used htmx, but it makes one way more productive in building websites that can behave like SPAs without the need for all the junk that one needs to get it going. All you need is html templates and a backend server. No JSX, no client side routing lib, no Node.js, no separate API server, heck coupled with something like Alpine.js you can get very far with little to no JavaScript, too (and it’ll still look and feel snappy). None of all the stuff we’ve been forced to use because of HTML’s incompleteness as hypermedia. The downside to this boost in productivity is when the need for a mobile app comes along, now you need a non-REST API, too. Then you can take out GraphQL or gRPC or something suited for the task. Your mobile client would most likely be using a different surface of the API even if you had one for web clients, so it’s not like you’re wasting much effort here.
infogulch 4y ago
You're not really contradicting the article, or the point of htmx. [1] Json-based Data APIs are for machines to interact with. Don't try to shoehorn REST semantics onto it, accept and embrace the fact that you are coupling tightly and proceed accordingly. But that still leaves space for Application APIs, where a human drives the client, and in that case REST/HATEOAS semantics work just fine. https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ We went on a wild goose chase trying to recreate a hypermedia client with javascript, contorting xmlhttprequest from an application api into a data api, on an already existing hypermedia client (the browser) because the latter stagnated and failed to fill out its functionality. htmx adds the missing functionality to make the browser a functional hypermedia client.
- habitue 4y ago
  you have inspired me to read more about htmx, but I will likely retain my bias against hypermedia
Tomte 4y ago
> Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. That's the point I've never understood, and maybe someone here can clear it up for me? As far as I understand, Fielding is constantly hammering on the point that navigation between resources should be hypertext-driven, so no "extraneous" information (where some resource or method is located) should be used. Only hypertext-style links from query/response to query/response. But HTTP has very generic verbs. GET, PUT etc. They don't mean much. Okay, REST proponents will say, while Fielding did his work in the context of HTTP, but envisioned a much richer hypertext capability. Good. Now I have verbs like "Resize photo" or "Follow user" or "Get GPS coordinates from EXIF" in my hypertext API? How is a generic client supposed to understand those? That's where I'm stuck. What's the use of it all if the client still needs to know everything about the domain (unavoidably, IMO)? Showing responses to the user and having him decide cannot be a real proposal, can it?
- yawaramin 4y ago
  { "response": { "actions": { "resizePhoto": { "method": "PATCH", "uri": "/photos/1", "body": { "w": "100", "h": "50" } }...
  - Tomte 4y ago
    Yes, that's the easy part. How does a client without extraneous information know that the action resizePhoto corresponds to the action that the user requested when dragging the image border inwards? The idea was a totally agnostic client, IIRC. You either tightly couple the client to the API or you need AI, don't you? And if the client needs to know that connection, how is that superior to having it do the PATCH dierectly?
    - hermanradtke 4y ago
      The same way a web browser knows how or interpret html. The client is written against the spec. The API drives the behavior, just like html does. This is great in theory, but very hard to do in practice.
JimDabell 4y ago
> HATEOAS doesn't solve any problems that we actually have. It’s the foundation of the World-Wide Web, which is the most successful platform in history. It solves a tonne of problems, that’s why it is so successful. You are using HATEOAS right now.
- skrebbel 4y ago
  GP addressed that, consider reading the entire comment before replying.
  - JimDabell 4y ago
    I did read it; they didn’t address it. You can’t say that it has no uses when it’s one of the most useful pieces of tech ever invented. “It only makes sense for HTML” doesn’t even come close to addressing that point.
- habitue 4y ago
  I commented in depth a little farther up in the tree, but the big difference between hypermedia in the web, and hypermedia in an API designed to be consumed by machines is the intelligence and judgement needed. It's a lot of work to make a very generic client that can navigate a hyper media API given only media types and link types. But it's trivial for a human because we can figure things out from context. Maybe once we can run gpt-3 on a mobile phone lightning fast, we can start building these fuzzy, flexible apis and not worry about breaking our clients. But in the meantime, it's a ton of work for very little gain.
  - recursivedoubts 4y ago
    https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
- amw-zero 4y ago
  No we're not, HATEOAS is a design pattern that no one uses. People use the web because it made self-publishing on the internet (which already existed) slightly easier.
tbrownaw 4y ago
HATEOAS gets things backwards. It's not useful to have a client that doesn't know what is supposed to be doing, but it's very useful to have a server that doesn't remember what the client's doing. Making sure that every request includes any state needed to answer it means the server doesn't have to track sessions.
- nerdponx 4y ago
  I don't think this is at odds with HATEOAS, as long as you can embed state in the hypermedia URLs. Or you could provide a set of URLs and state data or a JWT or whatever, and the client would combine them all together in operation.

Groxx 4y ago

>Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. Yeah, once I realized this, HATEOAS / "strict" REST immediately went into my "nope" bucket. It's pretty much fine for humans and makes some compelling decisions in that context, but it's wildly unusable and unstructured for literally anything else and that makes it almost useless. HTTP verbs and codes are plenty useful, and REST has been co-opted to mean "use verbs and codes correctly" and... I'm OK with that. It summarizes as "follow the patterns that much of the computing world relies on, so you don't break shit everywhere all the time" and that's something absolutely worth understanding and adopting in depth.

hudon 4y ago

I don’t know if you’ve used htmx, but it makes one way more productive in building websites that can behave like SPAs without the need for all the junk that one needs to get it going. All you need is html templates and a backend server. No JSX, no client side routing lib, no Node.js, no separate API server, heck coupled with something like Alpine.js you can get very far with little to no JavaScript, too (and it’ll still look and feel snappy). None of all the stuff we’ve been forced to use because of HTML’s incompleteness as hypermedia. The downside to this boost in productivity is when the need for a mobile app comes along, now you need a non-REST API, too. Then you can take out GraphQL or gRPC or something suited for the task. Your mobile client would most likely be using a different surface of the API even if you had one for web clients, so it’s not like you’re wasting much effort here.

infogulch 4y ago

You're not really contradicting the article, or the point of htmx. [1] Json-based Data APIs are for machines to interact with. Don't try to shoehorn REST semantics onto it, accept and embrace the fact that you are coupling tightly and proceed accordingly. But that still leaves space for Application APIs, where a human drives the client, and in that case REST/HATEOAS semantics work just fine. https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ We went on a wild goose chase trying to recreate a hypermedia client with javascript, contorting xmlhttprequest from an application api into a data api, on an already existing hypermedia client (the browser) because the latter stagnated and failed to fill out its functionality. htmx adds the missing functionality to make the browser a functional hypermedia client.

habitue 4y ago
you have inspired me to read more about htmx, but I will likely retain my bias against hypermedia

Tomte 4y ago

> Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another. That's the point I've never understood, and maybe someone here can clear it up for me? As far as I understand, Fielding is constantly hammering on the point that navigation between resources should be hypertext-driven, so no "extraneous" information (where some resource or method is located) should be used. Only hypertext-style links from query/response to query/response. But HTTP has very generic verbs. GET, PUT etc. They don't mean much. Okay, REST proponents will say, while Fielding did his work in the context of HTTP, but envisioned a much richer hypertext capability. Good. Now I have verbs like "Resize photo" or "Follow user" or "Get GPS coordinates from EXIF" in my hypertext API? How is a generic client supposed to understand those? That's where I'm stuck. What's the use of it all if the client still needs to know everything about the domain (unavoidably, IMO)? Showing responses to the user and having him decide cannot be a real proposal, can it?

yawaramin 4y ago
{ "response": { "actions": { "resizePhoto": { "method": "PATCH", "uri": "/photos/1", "body": { "w": "100", "h": "50" } }...
- Tomte 4y ago
  Yes, that's the easy part. How does a client without extraneous information know that the action resizePhoto corresponds to the action that the user requested when dragging the image border inwards? The idea was a totally agnostic client, IIRC. You either tightly couple the client to the API or you need AI, don't you? And if the client needs to know that connection, how is that superior to having it do the PATCH dierectly?
  - hermanradtke 4y ago
    The same way a web browser knows how or interpret html. The client is written against the spec. The API drives the behavior, just like html does. This is great in theory, but very hard to do in practice.

JimDabell 4y ago

> HATEOAS doesn't solve any problems that we actually have. It’s the foundation of the World-Wide Web, which is the most successful platform in history. It solves a tonne of problems, that’s why it is so successful. You are using HATEOAS right now.

skrebbel 4y ago
GP addressed that, consider reading the entire comment before replying.
- JimDabell 4y ago
  I did read it; they didn’t address it. You can’t say that it has no uses when it’s one of the most useful pieces of tech ever invented. “It only makes sense for HTML” doesn’t even come close to addressing that point.
habitue 4y ago
I commented in depth a little farther up in the tree, but the big difference between hypermedia in the web, and hypermedia in an API designed to be consumed by machines is the intelligence and judgement needed. It's a lot of work to make a very generic client that can navigate a hyper media API given only media types and link types. But it's trivial for a human because we can figure things out from context. Maybe once we can run gpt-3 on a mobile phone lightning fast, we can start building these fuzzy, flexible apis and not worry about breaking our clients. But in the meantime, it's a ton of work for very little gain.
- recursivedoubts 4y ago
  https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
amw-zero 4y ago
No we're not, HATEOAS is a design pattern that no one uses. People use the web because it made self-publishing on the internet (which already existed) slightly easier.

tbrownaw 4y ago

HATEOAS gets things backwards. It's not useful to have a client that doesn't know what is supposed to be doing, but it's very useful to have a server that doesn't remember what the client's doing. Making sure that every request includes any state needed to answer it means the server doesn't have to track sessions.

nerdponx 4y ago
I don't think this is at odds with HATEOAS, as long as you can embed state in the hypermedia URLs. Or you could provide a set of URLs and state data or a JWT or whatever, and the client would combine them all together in operation.