3 ms·

REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. The point of REST is to totally and generally describe the semantics of a net

REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. The point of REST is to totally and generally describe the semantics of a networked application's state transitions and is protocol-agnostic. GRPC exists to invoke remote functions. Why use REST? That's well-documented in Fielding's thesis [1]. Use the appropriate architecture for the appropriate task. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

dozzie 8y ago
> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. Though whenever somebody talks about REST API, they mean "almost RPC with underspecified semantics", not a hypertext driven way of fetching the data.
- madmax96 8y ago
  The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. RESTful architecture (e.g. the architecture that lets you use one client to consume literally billions of applications and provides the mechanisms for you to move between them totally transparently) works very well for building a specific kind of application. Now, most of us are not building the web, and so we have other constraints that are often times more important. You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. The way to escape this game of buzzword bingo is to introduce nuance to our conversations about architectures, not by changing the buzzword.
  - dozzie 8y ago
    >>> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. >> Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. > The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. Quite an apt observation: as consumed by humans. But we're comparing something that's commonly called "REST" to an RPC protocol, and RPC protocols are quite clearly intended for computers, not humans. This something that is commonly called "REST", even if you argue it's called incorrectly, is very far from the famous PhD thesis. > You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. OK. If you say that I'm wrong about implementations, show me where's a production system where the computer is the primary consumer (i.e. not merely a terminal for displaying something to a human operator, and not a second-class citizen like web crawling bots) and the system is RESTful in the original meaning. I can't think of even a single one. Note, however, that WWW cannot be considered such an implementation, because its primary consumer is human, not computer, and I remind you once again: we're talking under this post about unsupervised computer-to-computer communication, where human operator is a rare guest. > A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. Much less productive is trying to pull an unrelated idea (the original meaning of "REST") into discussion about machine-to-machine communication, especially that the original term was created post factum to describe WWW's architecture (already existing back then!) and wasn't used for pretty much anything else, so introducing the term hasn't advanced nor produced anything.
    - madmax96 8y ago
      We agree that ad-hoc RPC mechanisms are inappropriate. REST is not a RPC mechanism - people wrongly “using it” as one does not change what REST is, simply because there is a wealth of academic and industrial knowledge that uses REST in a specific way. This way is formally defined, and retroactively changing the meaning offers no immediate advantage. Again: when a statement “REST is worse than RPC” is evaluated, it implies to people (who are already obviously confused) that REST is worse than RPC. When people look at what REST is (i.e. Fielding’s thesis) they are further confused, because what Fielding describes obviously isn’t designed to compete with RPC. RPC existed when Fielding was writing his thesis and developing HTTP. He wasn’t solving the same problem. The best thing to do is to instruct what REST actually is so that the confusion is dispelled. Perpetuating ignorance only leads to more problems. Pointing out that REST is not an ideal mechanism for machine-to-machine communication is therefore extremely relevant. Fielding was heavily involved in the design of HTTP 1.1. The justification of the design decisions is REST and became his thesis. Implying that Fielding was disconnected from the design of the web is factually incorrect. Folks on Hacker News (where the web is obviously one of the most common application delivery mechanisms) might want to know how well-behaved web applications are constructed. That’s definitely relevant to this thread and community.

dozzie 8y ago

> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. Though whenever somebody talks about REST API, they mean "almost RPC with underspecified semantics", not a hypertext driven way of fetching the data.

madmax96 8y ago
The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. RESTful architecture (e.g. the architecture that lets you use one client to consume literally billions of applications and provides the mechanisms for you to move between them totally transparently) works very well for building a specific kind of application. Now, most of us are not building the web, and so we have other constraints that are often times more important. You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. The way to escape this game of buzzword bingo is to introduce nuance to our conversations about architectures, not by changing the buzzword.
- dozzie 8y ago
  >>> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. >> Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. > The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. Quite an apt observation: as consumed by humans. But we're comparing something that's commonly called "REST" to an RPC protocol, and RPC protocols are quite clearly intended for computers, not humans. This something that is commonly called "REST", even if you argue it's called incorrectly, is very far from the famous PhD thesis. > You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. OK. If you say that I'm wrong about implementations, show me where's a production system where the computer is the primary consumer (i.e. not merely a terminal for displaying something to a human operator, and not a second-class citizen like web crawling bots) and the system is RESTful in the original meaning. I can't think of even a single one. Note, however, that WWW cannot be considered such an implementation, because its primary consumer is human, not computer, and I remind you once again: we're talking under this post about unsupervised computer-to-computer communication, where human operator is a rare guest. > A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. Much less productive is trying to pull an unrelated idea (the original meaning of "REST") into discussion about machine-to-machine communication, especially that the original term was created post factum to describe WWW's architecture (already existing back then!) and wasn't used for pretty much anything else, so introducing the term hasn't advanced nor produced anything.
  - madmax96 8y ago
    We agree that ad-hoc RPC mechanisms are inappropriate. REST is not a RPC mechanism - people wrongly “using it” as one does not change what REST is, simply because there is a wealth of academic and industrial knowledge that uses REST in a specific way. This way is formally defined, and retroactively changing the meaning offers no immediate advantage. Again: when a statement “REST is worse than RPC” is evaluated, it implies to people (who are already obviously confused) that REST is worse than RPC. When people look at what REST is (i.e. Fielding’s thesis) they are further confused, because what Fielding describes obviously isn’t designed to compete with RPC. RPC existed when Fielding was writing his thesis and developing HTTP. He wasn’t solving the same problem. The best thing to do is to instruct what REST actually is so that the confusion is dispelled. Perpetuating ignorance only leads to more problems. Pointing out that REST is not an ideal mechanism for machine-to-machine communication is therefore extremely relevant. Fielding was heavily involved in the design of HTTP 1.1. The justification of the design decisions is REST and became his thesis. Implying that Fielding was disconnected from the design of the web is factually incorrect. Folks on Hacker News (where the web is obviously one of the most common application delivery mechanisms) might want to know how well-behaved web applications are constructed. That’s definitely relevant to this thread and community.