Justice Will Take Us Millions Of Intricate Moves
Conclusion: Meet George Jetson
George Jetson lives in the future and he works in a factory where all he has to do is push a button. He pushes it and robots do all the work. His job is literally a joke, and the joke is, you can design all those robots to do the work, but you can't design a robot to push a damn button?
Realistically, the George Jetson scenario isn't gonna happen. There's a limit to how much complexity you can automate away by building robots, because robots themselves are very complex machines.
If this scenario actually came to pass, George would still be busy. He'd be a robot psychoanalyst. And if you think about it that way, that is a lot like my job and your job. We're managing the complexity of the devices our civilization has created to manage complexity.
A lot of the work that's gone into web services is based on the idea that you can write the server side, or take what you already have on the server side, and push a button, and you've got the client side. That you can just hide the complexity.
You can't, for two reasons. The first is that, just like George Jetson's robots, the devices that hide the complexity are themselves very complex. In the web service domain, devices hide complexity by pretending the network boundary isn't there, which makes them brittle. They treat HTTP as though it were a transport protocol like TCP/IP, which makes them inefficient.
The second reason is that the button is not smarter than you are. If there is unneccessary complexity on your side, the button won't remove it: it'll be passed on. All your clients will have to learn the decisions you made and the shortcuts you took. This is the downside we encountered with publishing the Launchpad web service with a minimal set of annotations.
The answer is not to automate away the complexity but 1) to spread it around by splitting the complex thing into little pieces, 2) to reduce the complexity by treating things that are fundamentally the same the same way, and 3) to describe the differences between two complex things in a standard way, so that it's easy to get up to speed on one or the other.
These are roughly the lessons of URIs, HTTP, and HTML. If you combine those three technologies, you can spell out statelessness, hypermedia as engine of application state, and all the other restful constraints that confuse people. Or you can spell out the slightly different criteria I talked about in RESTful Web Services. They're all different ways to look at the same thing.
The thing I like about thinking in terms of the Web technologies is that they tie together history, theory, and modern-day practice. This way of looking at things casts the RESTful constraints in terms of the things we're all at least somewhat familiar with, and that gives you an easy way of judging web services and of making design decisions.
