I finally get REST. Wow.

I finally get REST. Wow.

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 the 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.

This generally sums up what I’ve been thinking about the whole SOAP stack. Java, .Net, all seem to wrap SOAP in something that looks like RPC — and results in lots of brittle implementation where making minor changes to the services causes incompatibilities. Admittedly, this isn’t *necessarily* true, but it seems like to have really loosely-coupled services, you need to be explicitly thinking about passing messages around, and designing a good forwards-compatible message/document format.

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. Because the protocol state is hidden, it is easy to get things wrong. For instance, you might call Process before calling Init.

and then…

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. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)

and the final, best piece…

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 to 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.

This really meshes with the direction my thoughts have been trending recently. RESTful services seem harder to design well, but more likely to be extensible and long-lived the same way the rest of the web infrastructure has been. It requires a web-way of thinking though. Much the way Web UI in AJAX-land means thinking about the fact that sometimes our users prefer web metaphors of desktop app interactions patterns.