What's in a name?

My recent posts are my attempt to describe how I think about the Web and how it can be leveraged to integrate systems independent of the browser. I got a ton of feedback in comments and email, which was all great. I’ve been away for a bit, so I thought it would be good to come back and summarize, and to ask a question about what to call the model I’ve adopted. Specifically, some worry that the term REST means too many things to too many people to have any real meaning at all. But before I get to that, let me summarize and respond to some of the key points people made.

Most of the feedback I got can be divided into a couple of bins...

First, that it’s just RPC. That’s wrong for all the reasons I listed in my last 4 posts.

Second, it’s not RPC, so it isn’t appropriate beyond browsing a hypertext graph of multimedia content. The first half is right. I strongly believe the second half is wrong, but we don’t have enough experience applying the model in other systems to say concretely. We need to get that experience.

Third, and most interesting, what you describe isn’t REST, for a range of reasons. Some of this was because I wasn’t crisp in defining the difference between managing system state, session state, and transitions between nodes in a protocol state machine. Clients make HTTP requests to move through a protocol state machine. This is completely unrelated to changing system state or to maintaining session state. Specifically, a GET is a move between nodes (or states) in the protocol, but does not (or should not) affect system state. I adopted the term “node” here to describe moving between states in the protocol state machine. Is that clearer?

Some felt I didn’t conform to REST because I didn’t include the notion of changes over time. Specifically, I said that each state in a protocol state machine has a URI, which I think is true. Each time the client enters this state, they get a representation of it. That representation may change over time. That doesn’t mean that each state in the protocol doesn’t have a unique URI, it means that each representation does not (unless you mix perma-links into the protocol).

The most important feedback worried about the fact that the Web isn’t really RESTian or that my model doesn’t align very well with the HTTP spec, which focuses on CRUD operations on entities. Let me address those concerns.

The Web does not fully conform to Fielding’s paper, but the reality is that the Web is RESTful enough. An implementation is never as pure as an idea (Look deeply the SOAP header processing model and the not-so-independent WS-* specs for another great example.). Yes, the modern Web uses cookies extensively, which don’t conform to Fielding’s ideas, but are extremely useful. More importantly, they do not sacrifice the notion of a stateless server, as long as there is a shared backend store. We could debate the merits of a stateless client vs. a stateless server, but the latter is how the Web really works, and pragmatically, that’s what I’m after, whether it conforms to Fielding or not.

About the model I’ve adopted not aligning with the HTTP spec, I disagree. The spec is written substantially in terms of CRUD operations on resources. The goal of the early Web was essentially distributed content publishing, the ancestor of the Wiki. The HTTP spec reflects that. We’ve moved well passed that problem domain to all sorts of other things, e.g., shopping at Amazon. It’s easy to think of the shopping process in terms of a protocol state machine. It’s harder to think of the content management problem that way, but you can if you try. In that problem space, the protocol state machine and the CRUD operations on entities converge into one model – in content management, the CRUD operations on the entities are the transitions in the protocol state machine.

I’ve been very careful in my last several posts not to get hung up on which HTTP methods are being used to transition between states. The HTTP spec positions the four main methods as equals, but I don’t look at it that way. POST is the core method. GET is an optimization that enables caching and, more importantly, makes it possible to bookmark protocol states as a single text string. PUT and DELETE made it in because of how the Web was first conceived. If it had started with the Amazon shopping cart, those verbs might not have been there. They might have been in an extension protocol, like WebDAV, but it didn’t happen that way. (Hopefully that isn’t too inflammatory.) I back up this position with the observation that while we encounter GET and POST all the time, PUT and DELETE are very rare. (Maybe APP will change that, but it hasn’t happened yet, and falls in the content management problem space for which those special verbs were defined anyway.)

But all of that is really moot. I don’t want to get lost in discussions or architectural styles, whether or the Web really conforms to Fielding (my answer is it conforms enough), whether REST and HTTP align, whether it is possible to be RESTian at all, the meaning of PUT and DELETE, or other distractions. I want to focus on digging into HTTP-based distributed state machines (a term I got from Sam) that leverage the pragmatic solutions for scalability, reliability, and security that we’ve developed on the Web.

So given all that, is REST the best term to use for this, or is there something better?