What is REST, Anyway?

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.

For example:

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



Filed under opinionizing, REST

4 responses to “What is REST, Anyway?

  1. Pingback: Distributed Weekly 90 — Scott Banwart's Blog

  2. I would argue that REST is not poorly defined for an architectural style. I just think we are not used to dealing with these kind of very high level definitions. I think REST is extremely misunderstood and there is a ton of misinformation floating around which makes it hard to learn. There are also lots of areas that are imprecise due to the fact that the context of the problem space needs to be understood before the right approach can be taken.
    You definitely seem to have grasped the spirit of REST and let me suggest that when you come across a REST “rule” that you don’t agree with, look for the reasoning. My experience has been the people who really grok REST can give you concrete, practical reasons why you shouldn’t break a rule. Those people who say, “it’s not RESTful” usually are just regurgitating dogma.

    • roby2358

      I agree, and maybe I was being too argumentative. There are a couple of things that complicate the discussion. The first is that most of REST is already implemented: client-initiated, stateless interactions with support for different flavors of requests. No one wants to talk about what’s already on hand. And the second is that the most important part — hypermedia — is still drastically lagging behind in support and understanding. So everyone gets hung up with the stuff in between, which we can control. But I’m thinking more and more that’s the least interesting and least important part.

      But I totally agree about concrete, practical reasons. I’m seriously starting to discount the people at my shop who can’t articulate why something is good or bad (REST-ful or not) because even within the architecture the value is the “why” behind the rule.

  3. Pingback: This Week in #REST – Volume 34 (Feb 9 2011 – Mar 6 2011) « This week in REST

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s