[Reprint] [rest] I finally get rest. Wow.

Yeah, I'm alive. And I remember the password to my blog. I'm ve been away for
Bit, working on something very cool involving the TV. If all goes well, you'll
Hear about it in a big way. Anyway, I'm still having a ball out here in reality.
Building something real has a way of focusing your decisions about technology.
My app is a distributed system, some of which runs in a cable plant head-end or
Telco Office (whatever's on the other end of the wire in your living room), and
Some of which runs elsewhere. We also connect to some things on the Web. These
Connections have to be extremely flexible and the bar to adoption has to be low.
The thing I finally realized (some of you will say "Duh !") Is that Web Services
Are not a good way to do this.

It's depressing to think that soap started just about 10 years ago and that
Now that everything is said and done, we built RPC again. I know soap is really
An XML messaging protocol
, You Can Do oneway async stuff, etc, etc, but let's
Face it. The tools make the technology and the tools (and the examples and
Advice you get) point at rpc. And we know what the problems with RPC are. If you
Want to build something that is genuinely loosely-coupled, RPC is a pretty hard
Path to take.

That realization wowould have gotten me down if not for the fact that something
Else jazzed me up an hour or so later. I was in the process of considering
Alternatives when I finally understood rest. And wow, It was eye-opening. Rest
Is often positioned as crud operations against entities identified by Uris. Then
It is dismissed as to simplistic to be useful. You can't build with just crud,
The reasoning goes, just think about why we write sprocs. I 've been down that
Path any number of times and always ended up in the same place. But I had it all
Wrong.

I skimmed Fielding's thesis a while back, but it wasn' t until I read Sam
Ruby's recent posts that it really sank in. 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
RPC, you build methods that modify the state of the communication. That State is
Maintained as a black box at the endpoint. Because the Protocol state is hidden,
It is easy to get things wrong. For instance, you might call process before
Calling init. People have been looking for ways to avoid these problems
Annotating interface type information for a long time, but I'm not aware of any
Mainstream solutions. The fact that the state of the Protocol is encapsulated
Behind method invocations that modify that state in non-obvious ways also makes
Versioning interesting.

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 between des 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. (The Atom publishing protocol is
The canonical example, though its easy to think that its about entities, not
State Machine .)

The "state machine as node graph traversed via URI" view of the world has
Really interesting implications for being able to suspend and resume a protocol.
Because links to other States are embedded in a State's representation there are
Interesting ways to solve dynamic load-balancing, data-directed-routing,
Versioning and other problems using normal Web infrastructure. And because it's
HTTP based, you get all the features that Protocol supplies, including streaming
And support for non-xml mime types (a huge concern when you're doing TV stuff ).
The one thing that's really missing here is a simple framework for implementing
A URI graph on top of an HTTP handler (similar to what Marc's been working on
For Java). I'm building my own now.

The thing I love about this model is that, as Sam says, it is of the Web, not
Over the web. That doesn't mean I'll use it for everything. I use TDS to get
SQL Server. I use WCF for RPC-style communication between Distributed Components
Within major systems. I'll use this model when I cross major system boundaries,
Especially when I don't own both sides. I'll let you know how it turns out.

 

Whether it is SOA or rest, it is actually to make the system have good performance and scalability.