Three reasons that REST is not RPC

I've gotten several comments saying that, at the end of the day, REST is just RPC. That's wrong, for at least 3 very reasons:

1) Each unique state in your protocol state machine has its own URI. That's different from an RPC endpoint that maintains a black-boxed state machine at a single endpoint. Being able to do state transition processing at disparate locations is hugely powerful. Watch the URLs you are navigating through as you browse, shop and checkout at Amazon. A single process can span machines offering differing levels of scalability, reliability and security.

RPC doesn't do that. You could conceivably build an RPC system that did do that, but if that happens it is a very rare occurence indeed. The more likely solution would be to have multiple RPC interfaces to the different machines involved in the process and then tie their protocols together. The application in the middle would have to understand how to mix the two protocols, passing data from one into the other, and back the other way. Yes, you can make it work, but it bakes a lot of protocol detail into the application mixing the calls, creating a much more complex solution.

2) With transition URIs embedded in the representations of states, it's easier to transition between states in the protocol. All of the URIs are accessed the same way, there is no separate interface per endpoint because the each endpoint represents the transition to an individual states, not all of the transitions required by a protocol. Again, technically this is doable with RPC, but nobody does it this way and solutions are more complex as a result.

3) The messages aren't interpreted as serialized call-stacks. The purpose of RPC is to copy a stack frame from one process to another, where it exists for the duration of a method call. That makes RPC very natural to anyone used to invoking a method, but it also makes it very hard to alter one side of the system without altering the other. While HTTP-based systems still use request/response messages, they aren't call-stacks. The fact that WS tools want to treat them that way is one of the reasons they have so much trouble handling large binary data, e.g., JPEG.

None of this is to say that RPC isn't useful. A couple people have mentioned callbacks to clients behind NAT based firewalls, a problem that RPC based on WCF duplex channels are very good at solving (protocols like XMPP and plain old TCP work well too). My system uses both RPC and REST. But it's a mistake to say that REST is RPC just because HTTP is request/response, we often use XML to represent state, and there are tools to map XML to and from callstacks. I made that mistake for a long time, until I realized what REST really is.