What is REST?
REST is a style of designing loosely coupled Web applications that rely on named resources — in the form of Uniform Resource Locators (URLs), Uniform Resource Identifiers (URIs), and Uniform Resource Names (URNs), for instance — rather than messages. Ingeniously, REST piggybacks on the already validated and successful infrastructure of the Web — HTTP. That is, REST leverages aspects of the HTTP protocol such as
POST requests. These requests map quite nicely to standard business-application needs such as create read, update, and delete (CRUD), as shown in Table 1:
Table 1. CRUD/HTTP mapping
|Application task||HTTP command|
By associating requests, which act like verbs, with resources, which act like nouns, you end up with a logical expression of behavior —
GET this document and
DELETE that record, for example.
Roy Fielding, the veritable father of REST, states in his PhD dissertation that REST "emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems" (see Resources). Building RESTful systems isn't difficult, and the systems are highly scalable while also being loosely coupled to the underlying data; they also leverage caching quite nicely.
Everything on the Web (pages, images, and so on) is in essence a resource. REST's reliance on named resources rather than messages facilitates loose coupling in application design, because it limits the exposure of the underlying technology. For instance, the following URL exposes a resource without implying anything about the underlying technology: http://thediscoblog.com/2008/03/20/unambiguously-analyzing-metrics/
This URL represents a resource — an article called "Unambiguously analyzing metrics." A request for this resource leverages the HTTP
GET command. Notice that the URL is noun-based. A verb-based version (which might look something like http://thediscoblog.com/2008/03/20/getArticle?name=unambiguously-analyzing-metrics) would violate REST principles, because it embeds a message, in the form of getArticle. You could also imagine posting a new resource (say, an article resource such as http://thediscoblog.com/2008/03/22/rest-is-good-for-you/) via HTTP's
POST command. Although you can also imagine associated, verb-based APIs — such as createArticle?name=rest-is-good-for-you and deleteArticle?name=rest-is-good-for-you — such calls hijack the HTTP
GET command and, for the most part, ignore the already available (and successful) HTTP infrastructure. In other words, they are not RESTful.
The beauty of REST is that resources can be anything, and how they are represented can vary too. In the preceding example, the resource is an HTML file; accordingly, the format of the response would be HTML. But the resource could have easily been an XML document, serialized object, or JSON representation. It really doesn't matter. What matters is that a resource is named and that communication with it doesn't affect its state. Not affecting state is important because stateless interactions facilitate scalability.
To quote Leonardo da Vinci, "simplicity is the ultimate sophistication." The implementation of the World Wide Web is as simple as it gets and an undeniable success. REST leverages the Web's simplicity and thus yields highly scalable, loosely coupled systems that, as it turns out, are simple to build.
As you'll see, the hardest part of building a RESTful application is deciding on the resources you want to expose. Once you've done that, using the Restlet framework makes building RESTful Web services a snap.