3 ms·

But REST is RPC. I've read the article and the author basically defines RPC as a HTTP API that doesn't use the HTTP methods in a semantically correct manner but

• sixdimensional 11y ago
  I agree with you. Too many get carried away with REST and don't think beyond HTTP. I do appreciate the author's work here, I think the author was trying to help people clarify that REST/RPC don't need to be exclusive and that is helpful. All too often we encounter developers who want to sound smart and cool and state that it is "this tech" or "that tech" or NOTHING! At a higher level of abstraction, representational state transfer should have nothing to do with HTTP semantics. It just so happens that we attribute REST with being related to HTTP semantics. But you could do REST with a non-HTTP protocol, if you wanted, why not? Similarly, you can use a non-HTTP protocol in any other kind of framework for network based communication that you wanted... And it just so happens that RPC is exposing functional, encapsulated units of code via network protocols and TCP/UDP sockets. I remember trying to write my own network protocols for fun before over TCP and UDP sockets. Simple things like an echo service or a simple client/server application protocol. Doing that helps give one context for REST, RPC, SMTP, FTP, and more - semantics, concepts and frameworks over network connectivity. The OSI model still matters. http://en.wikipedia.org/wiki/OSI_model http://en.wikipedia.org/wiki/OSI_model