> 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

> 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 ?