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

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