4 ms·

I don't think I've ever come across any third party actually implementing HATEOAS (https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS)

by spikej 5y ago

lowboy 5y ago
HATEOAS have always sounded like a delicious part of a healthy breakfast
- bluefirebrand 5y ago
  My brain drops the A, so I always read it HATEOS which makes me thinks it is a joke Linux distro of some kind.
zja 5y ago
That’s because no one knows what it is.
askme2 5y ago
At OSIsoft, they implement HATEOAS religiously. https://docs.osisoft.com/bundle/pi-web-api-reference/page/help/controllers/assetserver/actions/getdatabases.html https://docs.osisoft.com/bundle/pi-web-api-reference/page/he...
JimDabell 5y ago
Chrome, Safari, Firefox, Edge, and Opera are all third-party clients for the HATEOAS-based API known as the World-Wide Web.
- darkstar999 5y ago
  What?
  - progval 5y ago
    The web (HTTP + HTML + JS) intentionally fits the definition of a REST API. https://oleb.net/2018/rest/ https://oleb.net/2018/rest/ In particular: > The central idea behind HATEOAS is that RESTful servers and clients shouldn’t rely on a hardcoded interface (that they agreed upon through a separate channel). Instead, the server is supposed to send the set of URIs representing possible state transitions with each response, from which the client can select the one it wants to transition to. This is exactly how web browsers work
  - brigandish 5y ago
    The classic book on the subject is RESTful Web APIs[1], and it spends a while explaining HATEOAS by using the example of the web as we've come to expect it as the exemplar REST API using HATEOAS. I also have this essay[2] on HATEOAS in my open tabs, and it uses the example of a web browser fetching a web page. [1] https://www.oreilly.com/library/view/restful-web-apis/9781449359713/ https://www.oreilly.com/library/view/restful-web-apis/978144... [2] https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
    - incrudible 5y ago
      This should come with a big warning for people looking to do real work. This is not what most REST APIs are like in practice, nor what they should be. The vast majority of REST APIs are RPC-like, because that's the pragmatic way to deal with the problem 99% of the time. The "REST" branding is just for buzzword compliance.
  - incrudible 5y ago
    This answer is correct, but lacks context. REST wasn't conceived with APIs in mind. In fact, it's an awful fit for APIs, as many of the other comments point out. Rather, REST today is a buzzword that took on a life of its own, bearing only superficial resemblance to the original ideas. HATEOAS is a generalization of how something like a website would let a client navigate resources (through hyperlinks). It requires an intelligent agent (the user) to make sense. Without HATEOAS, according to Roy Fielding, it's not real REST. Some poor misguided API designers thought this meant they should add URL indirections to their JSON responses, making everything more painful to use for those unintelligent clients (the code that is consuming the API). Don't do this. If you must do REST at all - which should be up for debate - you should keep it simple and pragmatic. Your users will not applaud you for exhausting HTTP verbs and status codes. The designers of HTTP did not think of your API. You will likely end up adding extra information in the response body, which means I end up with two levels (status code and response) of matching your response to whatever I need to do. If something doesn't quite fit and it looks ugly or out-of-place, that's normal, because REST wasn't conceived with APIs in mind. Don't go down the rabbit hole of attempting to do "real REST". There is no pot of gold waiting for you, just pointless debates and annoyed users.
    - bluefirebrand 5y ago
      Absolutely agreed on all points. The best APIs I've ever used or built have been, at best, REST-ish. And generally the parts where they deviate from REST make them more usable, not less.
pmontra 5y ago
I used some API recently that returns URLs in the response body. It's really useful because they maintain those URLs and we don't have to rewrite our URL building code whenever the server side rules change. Actually we don't even have to write that code. It saves time, bugs, money. I don't remember which API was that, I'll update the comment if I do.
- berkes 5y ago
  Better yet, those URLs communicate what you may do. Instead of building the logic to determine if, say, a Payment can be cancelled, based on its attributes, you simply check 'is the cancel link there'. I find this a critical feature. Because between the backend, and various mobile clients, react, some admin, and several versions thereof, clients will implement such businesslogic wrong. Much better to make the backend responsible for communicating abilities. Because that backend has to do this anyway already.
bluefirebrand 5y ago
I had a new hire on my team criticize the API we built for our product because we don't use put or patch, and we don't allow a GET and POST to share the same path. He said "it's not very RESTful" I pointed him at HATEOAS and suggested if he wasn't familiar with it, he probably hasn't ever seen a truly RESTful API. I don't think I convinced him that our approach is good (I'm not sure I am convinced either, but it works well enough for our purposes) I do think I convinced him that "it doesn't correctly conform to a standard" isn't necessarily a useful critique , though. So that's a win.

I don't think I've ever come across any third party actually implementing HATEOAS (https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS)

by spikej 5y ago

I don't think I've ever come across any third party actually implementing HATEOAS (https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS)

lowboy 5y ago

HATEOAS have always sounded like a delicious part of a healthy breakfast

bluefirebrand 5y ago
My brain drops the A, so I always read it HATEOS which makes me thinks it is a joke Linux distro of some kind.

zja 5y ago

That’s because no one knows what it is.

askme2 5y ago

At OSIsoft, they implement HATEOAS religiously. https://docs.osisoft.com/bundle/pi-web-api-reference/page/help/controllers/assetserver/actions/getdatabases.html https://docs.osisoft.com/bundle/pi-web-api-reference/page/he...

JimDabell 5y ago

Chrome, Safari, Firefox, Edge, and Opera are all third-party clients for the HATEOAS-based API known as the World-Wide Web.

darkstar999 5y ago
What?
- progval 5y ago
  The web (HTTP + HTML + JS) intentionally fits the definition of a REST API. https://oleb.net/2018/rest/ https://oleb.net/2018/rest/ In particular: > The central idea behind HATEOAS is that RESTful servers and clients shouldn’t rely on a hardcoded interface (that they agreed upon through a separate channel). Instead, the server is supposed to send the set of URIs representing possible state transitions with each response, from which the client can select the one it wants to transition to. This is exactly how web browsers work
- brigandish 5y ago
  The classic book on the subject is RESTful Web APIs[1], and it spends a while explaining HATEOAS by using the example of the web as we've come to expect it as the exemplar REST API using HATEOAS. I also have this essay[2] on HATEOAS in my open tabs, and it uses the example of a web browser fetching a web page. [1] https://www.oreilly.com/library/view/restful-web-apis/9781449359713/ https://www.oreilly.com/library/view/restful-web-apis/978144... [2] https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
  - incrudible 5y ago
    This should come with a big warning for people looking to do real work. This is not what most REST APIs are like in practice, nor what they should be. The vast majority of REST APIs are RPC-like, because that's the pragmatic way to deal with the problem 99% of the time. The "REST" branding is just for buzzword compliance.
- incrudible 5y ago
  This answer is correct, but lacks context. REST wasn't conceived with APIs in mind. In fact, it's an awful fit for APIs, as many of the other comments point out. Rather, REST today is a buzzword that took on a life of its own, bearing only superficial resemblance to the original ideas. HATEOAS is a generalization of how something like a website would let a client navigate resources (through hyperlinks). It requires an intelligent agent (the user) to make sense. Without HATEOAS, according to Roy Fielding, it's not real REST. Some poor misguided API designers thought this meant they should add URL indirections to their JSON responses, making everything more painful to use for those unintelligent clients (the code that is consuming the API). Don't do this. If you must do REST at all - which should be up for debate - you should keep it simple and pragmatic. Your users will not applaud you for exhausting HTTP verbs and status codes. The designers of HTTP did not think of your API. You will likely end up adding extra information in the response body, which means I end up with two levels (status code and response) of matching your response to whatever I need to do. If something doesn't quite fit and it looks ugly or out-of-place, that's normal, because REST wasn't conceived with APIs in mind. Don't go down the rabbit hole of attempting to do "real REST". There is no pot of gold waiting for you, just pointless debates and annoyed users.
  - bluefirebrand 5y ago
    Absolutely agreed on all points. The best APIs I've ever used or built have been, at best, REST-ish. And generally the parts where they deviate from REST make them more usable, not less.

pmontra 5y ago

I used some API recently that returns URLs in the response body. It's really useful because they maintain those URLs and we don't have to rewrite our URL building code whenever the server side rules change. Actually we don't even have to write that code. It saves time, bugs, money. I don't remember which API was that, I'll update the comment if I do.

berkes 5y ago
Better yet, those URLs communicate what you may do. Instead of building the logic to determine if, say, a Payment can be cancelled, based on its attributes, you simply check 'is the cancel link there'. I find this a critical feature. Because between the backend, and various mobile clients, react, some admin, and several versions thereof, clients will implement such businesslogic wrong. Much better to make the backend responsible for communicating abilities. Because that backend has to do this anyway already.

bluefirebrand 5y ago

I had a new hire on my team criticize the API we built for our product because we don't use put or patch, and we don't allow a GET and POST to share the same path. He said "it's not very RESTful" I pointed him at HATEOAS and suggested if he wasn't familiar with it, he probably hasn't ever seen a truly RESTful API. I don't think I convinced him that our approach is good (I'm not sure I am convinced either, but it works well enough for our purposes) I do think I convinced him that "it doesn't correctly conform to a standard" isn't necessarily a useful critique , though. So that's a win.