3 ms·

REST doesn't have any official normative spec, there is no proper REST at first place. This is why I never liked the idea itself. And let's be frank, very few

REST doesn't have any official normative spec, there is no proper REST at first place. This is why I never liked the idea itself. And let's be frank, very few businesses are actually really doing representational state transfert. Most are just taking advantage of HTTP stateless properties with a coat of RPC on top. SOAP was heavy and complex but at least it had a spec, so no endless debate as to what "proper SOAP" was. It was up to libraries to either follow the spec or not, many did not. This is also why GraphQL adoption was so fast. Developers don't care about ideas if there is no spec to implement or reference implementation, most aren't academicians. edit: again, my comment is obviously referring to API, AKA 2 web apps communicating with each others, not an internet user clicking on links with an web browser.

jcrites 6y ago
> And let's be frank, very few businesses are actually really doing representational state transfert. Every website on the Internet is doing representational state transfer. REST describes the interaction of humans using browsers to visit websites. It's not (mostly) meant to describe APIs for use by machines. When you understand that it describes websites, then it's also not a hard concept to understand. Example REST services are: reddit.com, google.com, facebook.com, amazon.com, ebay.com, etc. Compare how you interact with these REST services with the criteria Fielding clarified in his blog post "REST APIs must be hypertext-driven": https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... When you build a website you typically meet these criteria without effort. It's a natural part of the experience. Machines can also interact with REST services, though usually not in the same way as people. (I agree that REST has minimal relevance to design of APIs that are intended for use by other software)
- throw_m239339 6y ago
  > Every website on the Internet is doing representational state transfer. REST describes the interaction of browsers with websites. It's not meant to describe APIs for use by machines. We're talking API here, obviously, AKA 2 web apps communicating with each other, through basic HTTP clients. A browser is anything but a basic HTTP client. There is no user clicking on links in a contextual fashion here. So the point you are trying to argue doesn't even matter. Your comment is ironically the very reason why REST as an idea is irrelevant to API developers and why trying to force a REST paradigm onto API is a bad idea. Very little HTTP clients used by API are sophisticated and intelligent enough to behave like an internet user browsing hyperlinks.
  - dreamcompiler 6y ago
    > Very little HTTP clients used by API are sophisticated and intelligent enough to behave like an internet user browsing hyperlinks. But they easily could be and should be. Obviously if only HTML is getting transferred, that's a difficult representation for a machine-based API to reason about. But XML or JSON is easy to teach a client to reason about. This is kinda the whole point of the Semantic Web and just about everybody missed it. So now everybody is finally actually doing Semantic Web [ish] stuff; they just call it GraphQL.
    - mathw 6y ago
      Actually no that's incredibly hard, because you have to specify somehow every possible relationship within your domain and write an engine which can use them appropriately.
pas 6y ago
REST is defined in Roy's dissertation, no? Sure, that's not a spec, but since rest is an architectural paradigm more than a concrete standard, it seems appropriate. Yes, almost no one needs 100% REST, browsers do basically. GraphQL adoption is not particularly fast IMHO, and being the official Facebook API probably helped :) Regarding your edit: REST is the generalization of users clicking links. That's why almost no one uses and needs full REST, because that kind of flexibility and future proofing is excessive in almost all business settings.

jcrites 6y ago

> And let's be frank, very few businesses are actually really doing representational state transfert. Every website on the Internet is doing representational state transfer. REST describes the interaction of humans using browsers to visit websites. It's not (mostly) meant to describe APIs for use by machines. When you understand that it describes websites, then it's also not a hard concept to understand. Example REST services are: reddit.com, google.com, facebook.com, amazon.com, ebay.com, etc. Compare how you interact with these REST services with the criteria Fielding clarified in his blog post "REST APIs must be hypertext-driven": https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... When you build a website you typically meet these criteria without effort. It's a natural part of the experience. Machines can also interact with REST services, though usually not in the same way as people. (I agree that REST has minimal relevance to design of APIs that are intended for use by other software)

throw_m239339 6y ago
> Every website on the Internet is doing representational state transfer. REST describes the interaction of browsers with websites. It's not meant to describe APIs for use by machines. We're talking API here, obviously, AKA 2 web apps communicating with each other, through basic HTTP clients. A browser is anything but a basic HTTP client. There is no user clicking on links in a contextual fashion here. So the point you are trying to argue doesn't even matter. Your comment is ironically the very reason why REST as an idea is irrelevant to API developers and why trying to force a REST paradigm onto API is a bad idea. Very little HTTP clients used by API are sophisticated and intelligent enough to behave like an internet user browsing hyperlinks.
- dreamcompiler 6y ago
  > Very little HTTP clients used by API are sophisticated and intelligent enough to behave like an internet user browsing hyperlinks. But they easily could be and should be. Obviously if only HTML is getting transferred, that's a difficult representation for a machine-based API to reason about. But XML or JSON is easy to teach a client to reason about. This is kinda the whole point of the Semantic Web and just about everybody missed it. So now everybody is finally actually doing Semantic Web [ish] stuff; they just call it GraphQL.
  - mathw 6y ago
    Actually no that's incredibly hard, because you have to specify somehow every possible relationship within your domain and write an engine which can use them appropriately.

pas 6y ago

REST is defined in Roy's dissertation, no? Sure, that's not a spec, but since rest is an architectural paradigm more than a concrete standard, it seems appropriate. Yes, almost no one needs 100% REST, browsers do basically. GraphQL adoption is not particularly fast IMHO, and being the official Facebook API probably helped :) Regarding your edit: REST is the generalization of users clicking links. That's why almost no one uses and needs full REST, because that kind of flexibility and future proofing is excessive in almost all business settings.