3 ms·

I don't think that's true, unless I just don't understand REST at all. Most "RESTful APIs" in the wild I encounter / implement are - stateless - cacheable - fo

I don't think that's true, unless I just don't understand REST at all. Most "RESTful APIs" in the wild I encounter / implement are - stateless - cacheable - follow client-server architecture - support resource identification in requests - loosely support resource manipulation through representation (with some caveats) I don't see how it's RPC by any but the most broad interpretation (a function executes at another address space).

tannhaeuser 4y ago
The entire point of Fielding's REST was loose coupling - that you don't hard-code interactions/URLs into clients but rather discover actions/links/interaction from representations dynamically, such that the only thing a client must know a priori is a URL. "REST API" practices are criticized because they follow all the rules and brag about eg HTTP response status code semantics and whatnot, but without following HATEOAS which is the entire point of it all. I can see why teams implement "REST APIs" - to end pointless architectural meta discussions and get stuff done; and there's practical value in that. But, harsh as it sounds, and I'm apologizing in advance if this is offending to anyone, dealing with colleagues who mindlessly follow REST casuistry feels like working with hopeless rote learners, psychopathic pretenders, or unstable personalities projecting naive, irrational, and premature ideas of craftsmanship into our profession to me.
- kareemsabri 4y ago
  I don't think that was the entire point. But who cares? Loose coupling is of little benefit to the client in a client-server pair that are implemented by the same company (which presumably Fielding wasn't picturing). There are other benefits people get from REST. Semantically understandable APIs, handlers that do one thing, predictable interfaces (this is close to as valuable as discoverable imo). I don't really get your point re: casuistry. The implementation of REST as practiced by the industry is largely pragmatic. The article appears to be arguing for REST purity.
  - masklinn 4y ago
    > I don't think that was the entire point. But who cares? People who like language to have meaning? > which presumably Fielding wasn't picturing Fielding was describing an architectural style. Although there may have been an element of advocacy, at the end of the day whether you used it or not was not his concern. > The implementation of REST as practiced by the industry is largely pragmatic. In the same sense that the implementation of airships in Boeing’s 747 is largely pragmatic, except for the part where Boeing doesn’t misscall their plane an airship. > The article appears to be arguing for REST purity. Much like saying a serval is not a dog is arguing for dog purity, yes.
  - hyperhopper 4y ago
    The benefit is then opening up the coupling to other clients. Like how Reddit used to have tons of apps before they started locking down all new functionality.
    - kareemsabri 4y ago
      Twitter had a ton of clients despite a REST API that was exactly like the OP was saying was not REST.

tannhaeuser 4y ago

The entire point of Fielding's REST was loose coupling - that you don't hard-code interactions/URLs into clients but rather discover actions/links/interaction from representations dynamically, such that the only thing a client must know a priori is a URL. "REST API" practices are criticized because they follow all the rules and brag about eg HTTP response status code semantics and whatnot, but without following HATEOAS which is the entire point of it all. I can see why teams implement "REST APIs" - to end pointless architectural meta discussions and get stuff done; and there's practical value in that. But, harsh as it sounds, and I'm apologizing in advance if this is offending to anyone, dealing with colleagues who mindlessly follow REST casuistry feels like working with hopeless rote learners, psychopathic pretenders, or unstable personalities projecting naive, irrational, and premature ideas of craftsmanship into our profession to me.

kareemsabri 4y ago
I don't think that was the entire point. But who cares? Loose coupling is of little benefit to the client in a client-server pair that are implemented by the same company (which presumably Fielding wasn't picturing). There are other benefits people get from REST. Semantically understandable APIs, handlers that do one thing, predictable interfaces (this is close to as valuable as discoverable imo). I don't really get your point re: casuistry. The implementation of REST as practiced by the industry is largely pragmatic. The article appears to be arguing for REST purity.
- masklinn 4y ago
  > I don't think that was the entire point. But who cares? People who like language to have meaning? > which presumably Fielding wasn't picturing Fielding was describing an architectural style. Although there may have been an element of advocacy, at the end of the day whether you used it or not was not his concern. > The implementation of REST as practiced by the industry is largely pragmatic. In the same sense that the implementation of airships in Boeing’s 747 is largely pragmatic, except for the part where Boeing doesn’t misscall their plane an airship. > The article appears to be arguing for REST purity. Much like saying a serval is not a dog is arguing for dog purity, yes.
- hyperhopper 4y ago
  The benefit is then opening up the coupling to other clients. Like how Reddit used to have tons of apps before they started locking down all new functionality.
  - kareemsabri 4y ago
    Twitter had a ton of clients despite a REST API that was exactly like the OP was saying was not REST.