Over the last few weeks I’ve been bored at work, and put off by the stupid politics, so I’ve been spending some time reading more about REST, refining my thinking, and opinionizing a lot on this blog.
I finally came to the conclusion that REST is not what a lot of people treat it as. It’s not a standard you can write a strict spec for, and then apply it to projects and declare “Yay!” or “Nay!” People do that, and that practice sinks a lot of projects, because it’s a silly practice.
REST, in itself, is hugely self-contradictory and ill-defined. For example, the idea of a Resource. It boils down to any information you have available that you want to expose through an API. How are you going to build a spec on top of a definition that broad and vague?
Then there’s the idea of statelessness. Roy Fielding says that “no session state resides on the server.” But what is session state? At what point do you draw a bright line between “session” state, and the state of a Resource you expose from the server?
Also, the requirement for hypermedia, which Fielding cites as a must-have, is something that hardly anyone at all is doing. Rather, we’re getting into long-winded, bare knuckle design discussions about URI design, when the whole point of hypermedia is to *hide* the URI.
Fielding himself states that a RESTful API must not lock itself into a fixed URI hierarchy. Which basically shoots a silver bullet through the skull of any yo-yo who gets fixated on pummeling everyone with their intricate, carefully structured family of hierarchical URIs.
Plus the whole fixation on a Uniform Interface misses the point that every API is different from every other — on purpose and necessarily.
Rather, I’m coming to see REST as ideas for addressing broad architectural concerns we’ve encountered and come up with nice solutions to in the years that the Interwebs have thrived.
- The power of client-initiated, stateless communications for handling distributed information.
- Being mindful about distributing and representing state, in a distributed system where information state is spread around.
- The power of hypermedia in communicating APIs as opposed to out-of-band communications.
- The utility of narrowing and standardizing your API methods in a way that’s familiar and consistent across a broad range of APIs.
There are some people who are dutifully fleshing out the details of REST, and producing software that honors the idea that there’s the idea of REST. But I think in the end REST will be important for spinning off some smaller, more finely-tuned specs such as:
- An RPC spec tailored closely to HTTP to take advantage of HTTP-oriented infrastructure in place today.
- The idea of proving basic functionality on addressable “noun” resources using HTTP methods, again leveraging existing HTTP infrastructure and narrowing APIs.
- How best to mix intention-based calls with noun-based calls.
- How to best manage machine-to-machine interactions through dynamically transmitted API specs — that is, hypermedia or some variation on it.
I think REST encapsulates a lot of really good ideas, and I think it’s well worth every web developer’s time to get intimately familiar with those ideas. But, in the end, I don’t think you can really have a “pure” REST architecture, because REST really isn’t just one coherent thing.
I actually think the most promising area in all this is the push to understand hypermedia better for machine-to-machine communications. I have this feeling that as thinking about that matures, it will loop back and inform our opinion of what we call REST today.
EDIT: more opinionizing… for example, what’s so wrong with a client POSTing a hypermedia document that contains a link that says, “If this resource changes, transmit the change to this location…”? That’s not RESTful, but I think it would make a ton of sense in a hypermedia-driven world. OK I’ll stop now.