An example might help...

I got a lot of great comments on last nights post, including a couple about REST being no different from xml-based RPC. I used to think so too, which is why my recent epiphany was so eye opening.

Consider a protocol for finding and reserving a flight between two cities. The client is in one of these states:

<ready>
- searched
- retrieved details
- reserved

These states map to URIs:

<none>
- http://quuxTravel.com/searched
- ??? depends on previous state
- ??? depends on previous state

A client begins by navigating to the searched state by GETting http://quuxTravel.com/searched?src=London&dest=NYC. The client gets back some XML like this:

<itineraries>
  <itinerary src=“London“ dest=“NYC“ price=“400.03“>
    <getDetails uri=“http://quuxTravel.com/details?itinerary=402“ />
    <reserve uri=“http://reservations.bookingsunlimited.com/quuxTravel?itinerary=402“ />
  </itinerary>
  <itinerary src=“London“ dest=“NYC“ price=“109.88“>
    <getDetails uri=“http://quuxTravel.com/details?itinerary=219“ />
    <reserve uri=“http://reservations.bookingsunlimited.com/quuxTravel?itinerary=219“ />
  </itinerary>
</itineraries>

The client is now in the searched state. It scans the list of itineraries to find the one with the lowest price. If the client wanted some other criteria that isn't surfaced in this state, e.g., total flight time, it could transition to the retrieved details state by GETting the URI stored in the itinerary's getDetails/@uri attribute. It would then return to the searched state (either by an explicit back-link or a history a la' the browser). The system would return an XML representation of that state that contained flight info.

When the client has chosen a flight, it transitions to the reserved state by POSTing to the URI stored in the itinerary's reserve/@uri attribute. It gets back an XML document confirming the reservation. At this point the protocol is complete. The client can begin again if desired, or go do something else.

Now, why is this different from RPC? Imagine the following interface for implementing this same protocol:

interface IFlightSystem
{
    Itineraries Search(string src, string dest);
    Details GetDetails(int itineraryId);
    Confirmation Reserve(itineraryId);
}

This interface exposes the same protocol, with more or less the same requirements on the client to know what the data being sent and received means. The difference is that in this case, the client is talking to one endpoint and mapping request/response payloads to call stacks. In the previous case neither of those things were true.

The REST model opens the door for the protocol to be implemented across different endpoints. This is useful for scalability, partitioning and data-directed routing, integration with external systems (note that the transition to the reserved state uses a URI at a partner company). In other word, it's actually a web of endpoints. Further, those URIs are dynamically constructed, so you can change them based on user, time of day, the data they're interested in, locale they're from, state of your data center, or whatever. That is hugely powerful. Because the documents being sent around are not mapped to call stacks, and may not even be mapped to objects, it's easier to stream data, add extra stuff over time, etc.

In one of his comments, Ittay asked what the REST model for the a method “string Foo(string, int, bool)” would be. In response, I described a simple protocol with one state, “FooInvoked”. To get to that state, you'd access a URI for /foo, passing a string, int and bool as query string parameters or in the request body. You'd get back a result state that contained a string. He countered that that felt just like a function call, which isn't surprising because that's where we started. The key, for me, is to look at problems not from the perspective of methods, as Ittay did, or entities, as Joe describes, but as states and the transitions between them. Then it really starts to make sense. And the power of it is real.