3 ms·

> And let's be frank, very few businesses are actually really doing representational state transfert. Every website on the Internet is doing representational s

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

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.