Visit Kevin Hoffman’s Blog

First, let me apologize for my lack of posting. I've been really busy taking up to 4 night classes per week and I'm working on a super ultra-top-mega secret book project with a friend and colleague. The only hint I can drop is that the book is going to kick ass. Look for more details soon!

Now, on to REST. I don't need to go into too much detail here about what exactly REST is - I know that most of the readers of this blog are well versed in Web Services technologies and architectural patterns. The thing that I want to cover is that REST is an architectural decision, it is not a protocol or a wire format or even an industry standard. It is a set of recommendations for how you organize the information exposed by your Web Services. Before I go into detail here, I personally think that REST is the way to go. Unless you have a particular need to be strapped into the SOAP/WS-* roller coaster, your Web Service should be exposing resources via RESTful URLs. I can't imagine why people would chose not to do so.

Here's a quick summary of the main tenets of REST in case you're not familiar with the concept:

• Application state and functionality are both considered resources. This is key to RESTful thinking - everything is a resource. Learn that phrase, love it, and live it.
• Every resource is addressable through a unique URL. Fielding's original paper on REST only requires a universal syntax, but if we're talking about Web services here, the universal resource address syntax is a URL. Hint: URL stands for Uniform Resource Locator.
• Every resource in the system shares a uniform interface for the transfer of state between the client and the resource (a decent, but somewhat stretched analogy is that a resource is the server in a client/server scenario). This means that the list of operations possible on a given resource is well-defined, and the list of content types describing the state being transferred is also well-defined.
  • HTTP already has a strict set of operations: PUT, GET, DELETE, POST (and optionally HEAD)
  • HTTP also has a strict set of available content-types.
  • Therefore, transferring state between RESTful URLs is ideally suited to being done over HTTP.
• According to Fielding (the first person to really put REST into the public eye), REST must be:
  • Client-Server
  • Stateless
  • Cacheable
  • Layered. This means that connected components within a system are unable to "see past" that which they are currently doing. A properly layered framework means that a layer can only see the 1 layer immediately below it, and no others.

I could attempt to summarize why I like REST so much, but instead there's a quote from Fielding's paper (which I believe is also in Wikipedia) that does the job way better than I could:

REST’s client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.

Before getting into the example, I feel the need to again state that REST is not a wire format. You cannot compare REST to SOAP, or REST to POX, or REST to JSON. They are not the same type of animal nor do they solve the same kinds of problems. REST is an architecture for designing distributed applications that calls for universally and uniquely addressable resources.