3 ms·

I might be unlucky but I've personaly never encountered a single REST API that implements HATEOAS (among many third party APIs I've integrated into softwares I'

by stymaar 10y ago

I might be unlucky but I've personaly never encountered a single REST API that implements HATEOAS (among many third party APIs I've integrated into softwares I've been working on on). If almost nobody who implements a REST API has HATEOAS in mind, doesn't it mean that REST is de facto independent from HATEOAS, no matter what the initial theoretician said about what REST should contain ? In other words, if REST mean something different for almost everybody than REST for the author (and a minority of people aware of the author's first intention), then in my opinion it doesn't mean that everybody is wrong about REST, it just mean that the word «REST» has evolved to a slightly more relaxed definition. This is also the claim of this talk: https://www.youtube.com/watch?v=6UXc71O7htc https://www.youtube.com/watch?v=6UXc71O7htc

masklinn 10y ago
> If almost nobody who implements a REST API has HATEOAS in mind, doesn't it mean that REST is de facto independent from HATEOAS If it's independent of HATEOAS what is in REST? If it's just doing HTTP, why not call it HTTP?
- stymaar 10y ago
  > If it's independent of HATEOAS what is in REST? Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. Back in 2005, it was really common to have only GET routes even for update of deletion, or worst: to have a single url: http://example.org/action http://example.org/action which concentrated all the API surface, different behavior being triggered by the type of the payload (JSON or even XML). Also, all the errors where `200 OK` but with a payload which contained the error. It was all done on top of HTTP but nothing was really using the HTTP tools (route + method + status code). Every single API / webservice had its own logic & semantic, working with 3rth party was a nightmare … It's exactly this kind of mess that the modern trend of «non-dogmatic REST» really solved. > If it's just doing HTTP, why not call it HTTP? Is it really REST ? No. Is everybody calling it REST ? Yes. Can we change how everybody calls it ? I don't think so, and I don't really think it matters. Many things are poorly named[1], but as soon as it gets to the popular language we need to use it for what it mean for people, not for ourselves. [1] Is a «quantum leap» a nano-scale step forward ? Where is the isomorphism in an Isomorphic web app ?
  - masklinn 10y ago
    > Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. That's literally got nothing to do with REST though, that's straight out of RFC 7231 (sections 4 "request methods" and 6 "response status codes") and the IANA HTTP Method Registry.
    - stymaar 10y ago
      You're right and wrong at the same time: - Technically REST and HTTP are two different things, I totally agree with you. - Historically, before REST became popular, people where doing complete nonsense on top of HTTP, with no respect of the spec whatsoever (see my comment above). This madness was stopped because of REST ! It's only when REST gained in popularity that people started to learn HTTP, and since then people developed a lot of semantically valid HTTP interface and called them REST API. To sum up my previous points : REST as imagined by Roy Fielding never caught, and the word REST is now almost unanimously used to describe «HTTP-compliant API». May HATEOAS rest in peace :)
macca321 10y ago
A while ago people started referring to 'true' REST APIs as Hypermedia APIs so on-topic discussion could be googled again. Accepting the redefinition of terms merely because they are popularly misunderstood is literally putting the inmates in charge of the asylum. wink

by stymaar 10y ago

masklinn 10y ago

> If almost nobody who implements a REST API has HATEOAS in mind, doesn't it mean that REST is de facto independent from HATEOAS If it's independent of HATEOAS what is in REST? If it's just doing HTTP, why not call it HTTP?

stymaar 10y ago
> If it's independent of HATEOAS what is in REST? Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. Back in 2005, it was really common to have only GET routes even for update of deletion, or worst: to have a single url: http://example.org/action http://example.org/action which concentrated all the API surface, different behavior being triggered by the type of the payload (JSON or even XML). Also, all the errors where `200 OK` but with a payload which contained the error. It was all done on top of HTTP but nothing was really using the HTTP tools (route + method + status code). Every single API / webservice had its own logic & semantic, working with 3rth party was a nightmare … It's exactly this kind of mess that the modern trend of «non-dogmatic REST» really solved. > If it's just doing HTTP, why not call it HTTP? Is it really REST ? No. Is everybody calling it REST ? Yes. Can we change how everybody calls it ? I don't think so, and I don't really think it matters. Many things are poorly named[1], but as soon as it gets to the popular language we need to use it for what it mean for people, not for ourselves. [1] Is a «quantum leap» a nano-scale step forward ? Where is the isomorphism in an Isomorphic web app ?
- masklinn 10y ago
  > Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. That's literally got nothing to do with REST though, that's straight out of RFC 7231 (sections 4 "request methods" and 6 "response status codes") and the IANA HTTP Method Registry.
  - stymaar 10y ago
    You're right and wrong at the same time: - Technically REST and HTTP are two different things, I totally agree with you. - Historically, before REST became popular, people where doing complete nonsense on top of HTTP, with no respect of the spec whatsoever (see my comment above). This madness was stopped because of REST ! It's only when REST gained in popularity that people started to learn HTTP, and since then people developed a lot of semantically valid HTTP interface and called them REST API. To sum up my previous points : REST as imagined by Roy Fielding never caught, and the word REST is now almost unanimously used to describe «HTTP-compliant API». May HATEOAS rest in peace :)

macca321 10y ago

A while ago people started referring to 'true' REST APIs as Hypermedia APIs so on-topic discussion could be googled again. Accepting the redefinition of terms merely because they are popularly misunderstood is literally putting the inmates in charge of the asylum. wink