So my colleague Snookie asked me the other day, “What’s this REST thing I keep hearing about?” So I said “Well Snook, Representational State Transfer, or REST, is an architectural style for distributed hypermedia systems.” Snookie, being the intelligent software engineer that she is, quickly responded: “Thanks, that really cleared things up.”

The End.

Actually, that never happened, and Snookie doesn’t really exist, but stories are supposed to make things more interesting. Did it work?

So if you’ve read this far you must really want to know more about REST, here we go. Let’s start with some background. The quoted definition back there for REST was from a guy named Roy Fielding, who coined the term REST in a dissertation that he wrote all the way back in 2000. “So long ago?” you might ask. Yes, the REST architectural style, is essentially a set of constraints placed upon an architecture to evoke certain desirable properties. The particular constraints of REST were chosen to specifically guide the growth of the web.

So what does all this have to do with web services? Well, on a late night about four years ago this guy named Topher was working on a SOAP web service for his online bookstore. All the sudden his WSDL exploded, XML went everywhere and all his envelopes were destroyed. After that night he vowed to never abuse HTTP in that way again. Ok, so I just made up another story, its kind of addictive.

But if Topher was a real person, what he would have meant was that his web service really should take advantage of the system that its being run on, THE WEB! That’s where RESTful web services come in. As I said before, the constraints of REST were used to guide the development of the web (HTTP, URIs, HyperText, etc.). RESTful web services take advantage of the architecture of the web, where as other types of web services (SOAP, RPC) simply ride on top of it.

Let’s look at an example. One of the constraints of the REST style is the uniform interface. A uniform interface between client and server makes for a simpler, decoupled architecture. One aspect of a RESTful web service’s uniform interface is the set of HTTP verbs. HTTP defines several actions that a client can take on a resource the most common of which are GET, POST, PUT, and DELETE. Each of these actions is very well defined and clear on what it does and does not do. A RESTful web services strictly adheres to the rules for these actions. This allows for every client to know the precise meaning and ramifications of its requests.

In contrast, a SOAP web service running on the web uses the POST action for every request. This obscures the nature of the request from the outside world and ignores the design of HTTP.

Another constraint of the REST architectural style is the cache constraint. The cache constraint requires that data within a request be explicitly labelled as cacheable or non-cacheable. The web implements this constraint through standardized HTTP headers and directives. RESTful web services can take advantage of this work, allowing any client or intermediary layer to cache requests appropriately.

Hopefully at this point I’ve given you a general overview of what REST is and why it makes sense. This is just the tip of the iceberg my friends. I’ll be back soon to give you all sorts of practical information about designing and implementing RESTful web services.

So run along and tell your boss’s boss that REST is going to solve all your problems!

JP
Cultivate Collaboration, Drive Innovation

DISCLAIMER: I assume no responsibility for you telling your boss’s boss that REST will solve all his problems.