In my evolution as an applications developer I’ve stumbled upon certain technologies that excited me. These were the more obvious things at first, like discovering the power of design patterns or unit testing. But the last one that has really been tickling me is Representational State Transfer, or REST for short. And I find myself more excited about the promise of REST than anything else I’ve encountered so far in my journey.
Representational State Transfer (REST) is a set of architectural guidelines defined by Roy E. Fielding, in his dissertation on the design of the World Wide Web[1]. In short, it describes how resources that live on the “web” are requested and modified by agents outside of the web. This includes the medium (TCP/IP), the protocol (HTTP), and the representation (HTML). Sounds like the W3C specification, right? Well that’s because Roy also co-authored those.
There are many[2] resources[3] on what REST is, so rather than go over the specifics I’ll just highlight the guideline and the things I find interesting about it. There’s a huge emphasis on resource-orientation in REST. That is, the angle taken when thinking about objects isn’t so much in terms of what they do but more about what they are. To further the contrast: object-orientation pre-occupies itself with the blueprint of objects to understand how they may interact, where as resource-orientation is more concerned with what the object looks like, and leaves the interactivity out. This in isolation makes little sense, but if you think about the web, there are basically two messages that are sent most of the time: GET and POST. Resource-orientation assumes that at some point resources should handle GET, POST, and other HTTP-specification messages, and thus leaves out the behaviour of resources. Instead, it focuses on what the resource looks like, or in other words, its state.
Imagine a world where every object had a basic uniform interface – the HTTP-specification-based methods – and rather than manipulation of objects (in terms of messages you can send and receive) you focus on manipulation of state instead, and you start warming up to the core of REST.
The other thing noteworthy about REST is its emphasis on the importance of Uniform Resource Identifiers (URIs). A URI is the way a resource is published, and thus it is critical that it have a unique namespace, as well as a descriptive name. The URI is the handle through which agents can grab a hold of a resource and do something with it or to it. Without the presence or uniqueness of this identifier, the world of resource-orientation grinds to a halt.
To review, in light of these clarifications: REST is an architectural guideline whereby resources are uniquely identified and their states are managed by a uniform interface, such as the HTTP methods.
REST might still be a bit blurry, so I’ll contrast it with another process guideline that plays its antagonist: Remote-Procedure Call (RPC). In RPC, you send a message from one end of a wire to the other end of the wire, where a recipient waits for messages and optionally responds in kind, over the wire, back to the originator with some kind of response. This is object-oriented for the same reason it’s not resource-oriented (RESTful): the concern in this process model is the objects and the messages, not the resources and their state. A REST approach wouldn’t expose a list of possible messages an object could receive (think: verbs/actions) over a wire, but rather expose a representation of the resource’s state (think: nouns/representations) over the wire. All the while managed by sending one of a core set of messages you’d use with any other resource, the response differing only in how that resource would handle the message. The core set that’s been implemented are the HTTP methods and resources named via URIs, which are generally (and for good reason) associated with REST.
“Manage resource-state instead of the resource itself? That’s crazy talk!” But it’s really no crazier than thinking when you instantiate an object, you really have that object. In the end, objects and messages are facade for resources and resource-state. Representations of objects in memory, each with easy-to-grab handles to manipulate them. REST actually brings us closer to the machine (in terms of abstraction).
I’ll give a simple example to help bring the point home. Imagine we have to model a light bulb. Putting on our OO thinking caps, we start thinking that it has certain properties (colour, size, power) and at least one function: toggle on/off. Putting on our RO (resource-oriented) caps on, we think it has to live somewhere (e.g., silvanolte.com), it has to have a unique name in that place (e.g., light-bulb.html), and its state is managed by the HTTP method used to interact with it (e.g., GET retrieves a light bulb, POST changes the state of a light bulb, such as whether it’s on or off, and DELETE would delete a light bulb – one URI, three different HTTP methods). In OO, we now create other object to interact with our shiny new light bulb, whereas in RO we now simply interact with it through an already available client (e.g., web browser) or write a custom client to interact with it. (This last point is rather powerful, but that may not be immediately apparent. As I continue the series, I will revisit this and show you exactly why.)
And these are just some of the reasons why I am smitten by REST. It challenges my foundation for how I approach computing problems (object-orientation) , specifically dealing with web application design and, to a greater extent, web services implementation. It nudges me in different ways when I look at how I build my model, and how I expose parts of it in a web application. Focusing on resource- and state-management gives me a different look and, combined with an object-oriented perspective, provides a wider picture from which I can draw design cues.
Resource-orientation fits the web model better. Process models like RPC act more as an adapter process than an embracing of the underlying infrastructure. While some levels of indirection provide great benefit for the introduced complexity, going beyond resources and their states is hard to justify. It’s what the web was designed for, and adding facades to make the web fit our paradigms for application development, while the web’s infrastructure is sufficient, introduces needless complexity. That brings me to my next point...
I love simplicity, and REST is, at its core, very simple. Simpler designs has less room for error and are easier to manage. Resources, whether static or logical, exist given their URI (their “handle”) and are accessible to you. Simply apply an HTTP Method to a URI to get some representation of it, changing its state along the way (in the very least, it changes for no other reason than your interaction with it). No messy end points. No complicated RPC calls. Simple design that is extensively powerful in its application.
And besides, it’s hard to argue with results. The World Wide Web is as successful a platform as there’s ever been in the computer science space. From humble beginnings to supporting full-blown services such as Word Processing and Data Mining, the Internet has revolutionized the way we work and live. And if you look carefully, you’ll notice this is not in spite of REST, but in large part because of it.
Finally, I like REST because I see a lot of potential. I consider all the questions that come to mind when I think about the Web, its design, and how Web Applications work, and I see a lot of room for innovation and growth based on a RESTful foundation. There’s a lot of upside to this approach, and when I superimpose it over everything I’ve learned to date about web applications, web services and all the concerns that come with them (session management, transaction management, scalability, performance, security) there seems to glowing paths to new levels of enlightenment. And there’s only one way to know: I must make the journey and see what’s there.
In a nutshell, that’s REST, and that’s why I like it. In the next few weeks I’m going to delve deeper into RESTful application design and share bits of code I’m writing to illustrate some of the powerful things you can do with this simple paradigm. We’ll write a service, and write different kinds of consumers (desktop application, web application, and finally web service), and see where REST shines brightest.
We'll also look at what libraries and frameworks that exist today to help anybody put together a RESTful architecture. Some are great, and some are complex again (defeating the purpose!) but they all have something interesting to offer. We'll explore what niches are left to fill, and perhaps even start an open souce project to address some of these concerns.
All in all, It is my hope that in sharing with you parts of my journey into REST you too will get something meaningful out of it, and blaze your own RESTful evolution in your projects. Just remember to give back, so we can all grow together.
[1] Fielding, Roy T.; Taylor, Richard N. (2002-05), "Principled Design of the Modern Web Architecture" (PDF), ACM Transactions on Internet Technology (TOIT) (New York: Association for Computing Machinery) 2 (2): 115–150, doi:10.1145/514183.514185, ISSN 1533-5399
[2] Representational State Transfer – Wikipedia: http://en.wikipedia.org/wiki/Representational_State_Transfer
[3] Building Web Services the REST Way: http://www.xfront.com/REST-Web-Services.html