Skip to main content

REST as State Machine - Duh!

Posted by davidvc on April 27, 2007 at 10:19 AM PDT

Years back I took a three week training on OO modeling using the Shlaer-Mellor method, which has now been pretty much subsumed by UML. One thing I spent a lot of time doing was designing the behavior of a system using state diagrams.

Fast forward to 2007, and I'm trying to get my head around REST. I like it, but I don't know why sometimes -- it seems too simplistic to capture rich application semantics.

It looks like I was not the only one.
Tim Ewald shared his "aha" moment
, and it clicked for me too.

Tim says Here's what I came to understand. Every communication protocol has a state machine. For some protocols they are very simple, for others they are more complex. When you implement a protocol via RPC, you build methods that modify the state of the communication. That state is maintained as a black box at the endpoint.


The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you're moving to, making that your new state. A state's representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app's protocol can't work that way too.

It's not necessarily easy to think this way when defining an application protocol for those of us that aren't used to it, but the benefits are significant.

In a past incarnation I was responsible for architecting a clustering solution for Sun's app server, such that session state is available to every instance in the cluster. Doing this is not easy, and it's not cheap (in terms of performance). With this experience behind me, I find REST very compelling. It defines a way for you to build simple, flexible, scalable apps using HTTP as it was meant to be used, rather than shoving RCP and embedded session state onto it, and this means your web infrastructure can really take advantage of the stateless nature of HTTP to provide high scalability and flexibility.

Of course, I have yet to build a REST-based application, and the devil is in the details. Those of you who are out there in the wild trying to build this stuff -- what is your experience?