There’s been a recent mini-flurry around REST and alleged subsets such as “Lo-REST” and “Hi-REST”. Initiator: Don Box. Responses: Obasanjo, Jonnay, Glazkov, Megginson, and Tomayko. My thanks to all of them for keeping this stuff in the front of my mind. I’m not sure that “Web Services” and “REST” are useful names for the interesting network-application styles. But I’m pretty sure I know what those styles are.
I’d really like to write this without using the word “architecture”, which has been abused long past the pain point. Roy Fielding calls REST an “Architectural Style” but I’m not sure that’s an improvement. I’m going to talk about application styles, or just styles; shorter is better.
History · It might be helpful to remember what the goal is, what we’re trying to accomplish. We want to build applications that work across networks, where the networks have unpredictable scale and performance and reliability, and the computers in the networks aren’t all the same. That’s all.
Since programming frameworks had always been about APIs and Object Models, the first wave of attempts to build network frameworks, logically enough, tried to extend those things across the network. It didn’t work that well: those frameworks were hard to understand and hard to implement and interoperability suffered.
Then, in the first half of the Nineties, there finally was a big complex information system that extended across the Internet and performed well and did useful things. That, of course, was the World Wide Web.
Message Exchange Patterns · When you look at the Web, you see no APIs and no object models; it’s protocols all the way down. The system is defined by agreements on the sequencing and contents of the messages going back and forth. The agreements can be precise (TCP/IP) or sloppy (HTML), they can come from the IETF or the W3C or ISO, it doesn’t really matter that much; what matters is that messages are all there is.
What most people call “Web Services” is an application style built around Message Exchange Patterns (MEPs for short). Based on the Web’s success, the idea is hard to argue with. The mainstream attempt to standardize this style started with XML and XSD and WSDL, and then plunged headlong down the WS-* path.
I think "MEP Style" or "Message-Exchange Style" would be a better name than "Web Services".
The Web Style · When you look at the Web and see past the message-exchange basics, a few more things leap to the eye: HTTP’s highly-restricted MEP, the notions that everything is a Resource and identified by a URI, and the importance of hyperlinks as a general-purpose building block.
What most people call REST is a an application style that shares those basic Web underpinnings. Specifically:
You have a lot of things in the system, identified by URIs.
The protocol (probably HTTP) only knows one MEP: single-request, single-response, with the request directed at a URI.
An important subset of the requests, what HTTP calls GET, are read-only, safe, idempotent.
You expect to ship a lot of URIs around in the bodies of requests and responses, and use them in operations that feel like link following.
I think “Web Style” would be a better name than “REST”. Serious students of the style will still need to read Roy’s dissertation, but I think those bullet points capture the essentials.
Red Herring: Statelessness · Statelessness isn’t an architectural fundamental, it’s a useful engineering technique for making distributed systems scaleable. Lots of Web-style applications keep all sorts of client state on the server and they work just fine. Those ones probably won’t scale up to serve all of humanity across the Internet, or even a hundred thousand busy online shoppers, but there are lots of useful apps that don’t need that kind of scale.
Red Herring: HTTP Verbs · The notion that you can usefully classify systems according to whether or not they use HTTP PUT and DELETE is silly.
There are two kinds of operations against a resource in the system: those that can change its state, and those that can’t. Operations that remove a resource (DELETE) or replace its whole content (PUT) are a small and not particularly interesting subset of potential state changers. It’s possible that you can introduce certain system optimizations by recognizing these up front and optimizing their routing and so on; plausible even, but unproved in practice, and unlikely to be a game-changer.
What To Do? · I think we should take the “Web Services” label into the jailyard, strap on a blindfold, give it a last cigarette, and shoot it. It doesn’t mean much any more, and to the extent that it does, it’s misleading: WS-* doesn’t have much of the Web about it. I don’t have a proposal for a new name for the WS-* style; sorry, but I just don’t care.
But I know what kind of software I’m interested in: Web-style software.
It’s here today, it works, it’s standards-based, and there’s a huge opportunity for building tooling and developer support around it.
