3 ms·

> REST is still a bit simpler ... I don't want to take away from your main point, but I wish at least on HN we could use the term "REST" with its proper meanin

> REST is still a bit simpler ... I don't want to take away from your main point, but I wish at least on HN we could use the term "REST" with its proper meaning, but maybe it's a lost cause. REST has nothing to do with JSON-over-HTTP or pretty endpoint URLs. REST and HATEOAS is about minimal, stateless coupling of web clients and server apps. The idea is that you point your browser at an endpoint, and the user/browser drives forward every further interaction and state evolution by hyperlinks and other affordances presented in the return "representation" (eg. HTML). Specifically, the web client isn't supposed to do requests against out-of-band provided URLs for JSON or other payloads with hard-coded endpoints. I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated its inventor since at least 2008 [1]. Edit: as discussed many times here eg. [2] [1]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... [2]: https://news.ycombinator.com/item?id=3635085 https://news.ycombinator.com/item?id=3635085 - Nobody understands REST or HTTP

bonesss 9y ago
> I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated [basically everyone] Amen, sister. JSON RPC over HTTP is... you know... the 99% use case. HATEOAS has its place, but IMO and IME that place isn't most of what industry is doing. For whatever reason, though, there is a buzz about actual-REST and HATEOAS that seems both ignorant of the original intent of REST/HATEOAS and of practical development considerations. REST-fullness has been an undefined architectural ideal for over a decade now and shows no signs of convergence of clarity... I would really like a new buzzword for JSON RPC so that I know what the heck people are talking about when they talk about REST. I am tired of guessing, and tired of listening to consultants was poetic about HATEOAS who have clearly never read the white paper... :)
gr__or 9y ago
I hear this a lot but I think the point is moot. It kind of reminds me of communists telling me that real communism has never been tried. Okay okay I know, analogies are sinful. Sorry! My point is that this pure definition of REST doesn't conflict with what the parent comment outlined. I'd go even further and say that to implement in this purer, Content-Type agnostic, state-evolution by hyperlinks kind of way makes the implementation even harder (around as hard as it is to implement a GraphQL endpoint).

bonesss 9y ago

> I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated [basically everyone] Amen, sister. JSON RPC over HTTP is... you know... the 99% use case. HATEOAS has its place, but IMO and IME that place isn't most of what industry is doing. For whatever reason, though, there is a buzz about actual-REST and HATEOAS that seems both ignorant of the original intent of REST/HATEOAS and of practical development considerations. REST-fullness has been an undefined architectural ideal for over a decade now and shows no signs of convergence of clarity... I would really like a new buzzword for JSON RPC so that I know what the heck people are talking about when they talk about REST. I am tired of guessing, and tired of listening to consultants was poetic about HATEOAS who have clearly never read the white paper... :)

gr__or 9y ago

I hear this a lot but I think the point is moot. It kind of reminds me of communists telling me that real communism has never been tried. Okay okay I know, analogies are sinful. Sorry! My point is that this pure definition of REST doesn't conflict with what the parent comment outlined. I'd go even further and say that to implement in this purer, Content-Type agnostic, state-evolution by hyperlinks kind of way makes the implementation even harder (around as hard as it is to implement a GraphQL endpoint).