Section 6.0. Introduction

6.0. Introduction

Contributed by: Ryan Daigle

Shortly before the first Rails conference, David Heinemeier Hansson began work on a profoundly new approach to designing and developing Rails applications. His keynote speech at that conference was titled "Resources on Rails." The presentation introduced the idea of resource-oriented Rails development and a software architecture called Representational State Transfer, or REST.

REST is an architecture that was initially proposed by Roy Fielding in his PhD dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). It allows you to build full-featured and extensible web services and applications on top of a small set of core, foundational operations. These operations are the standard HTTP request methods (GET, POST, PUT, DELETE), of which you may only have experience with GET and POST. Web development has long ignored the full HTTP specification and has piled undue responsibility on the GET and POST methods, forcing them to shoulder the full load of requesting and sending data to and from dynamic web applications. But these request methods, these verbs, are the core of a very simple but expressive design methodology.

REST Is a Conversation

REST is about breaking down HTTP requests to a natural, human-language type structure where there are verbs and nouns. The verbs of the REST conversation are the aforementioned request methods, while the nouns are URIs, unique identifiers for some resource accessible via the Web. The term "resource" is used to describe anything that is accessible via the Web: think of a book on Amazon or an item on eBay. Their URIs are identifiers to those actual items, those resources.

Too often we ignore this very basic sentence structure by forgetting that there are verbs that indicate action, and instead use the URI to specify our intent. What this means in technical terms is that this request:

GET "/books/destroy/1"

is overloading the URI. A URI should be only a pointer to a resource, and this request forces it to denote both the resource (a particular book) and the action to take on that resource (destroy). Our goal is to maintain the integrity of URIs as pure nouns by using this request instead:

DELETE "/books/1"

Here we have a URI that indicates one and only one thing, the location of a book. The request method, DELETE, indicates the action to take on that book.

There are often unforeseen consequences when the request methods are not properly used, e.g., when GETs are used to ask for the deletion, destruction or modification of a resource. One of the most well-known consequences is when browser page-fetching tools preload pages that are linked from the user's current page. The fetching tools find all GET-requested resources (links) and make a request for them in anticipation of the user requesting that link at some point in his browsing session. However, when links to do things like delete user accounts are blindly constructed using GET, the page-fetching utility actually invokes the destructive or modifying request. By strictly adhering to REST and using GETs only for idempotent requests, we can avoid these unintentionally destructive situations.

REST Is Design

At this point, you might be asking yourself if REST is only about the semantics of speaking HTTP. No, REST is not only about properly utilizing the grammar of HTTP, it's also about mimicking the conciseness and intentional terseness of the HTTP verbs in the design of your application.

Good design is not about the complexities involved with solving simple tasks. It's about the simplification of complex ones: boiling problems down to their bare essentials so that they can be properly analyzed, properly represented, and properly addressed. REST gives us a framework for simple but extensible application design by mandating what actions an application can support against a resource:

GET

Reads a resource

POST

Creates a resource

PUT

Edits a resource

DELETE

Deletes a resource

Many other common requests can be built on top of these verbs. Search is really the reading of resources that meet certain criteria. Publishing a post is really just setting the publish property to true. Forcing ourselves to speak and think in this brief but complete form lets us build on simple application designs with simple APIs to create full-featured applications. And by sticking to this uniquely well-suited and terse structure, we can let our frameworks provide the foundation.

Rails and REST

There are strong parallels between the REST verbs, the basic Rails controller actions (CRUD), and the ACID operations of SQL. What Rails does so wellprovide a quick and easy way to retrieve data from a database and return it to the web tierfits nicely within these parallels.

Figure 6-1 shows how the verbs of SQL (or ACID) and HTTP correspond to each other.

Figure 6-1. CRUD, HTTP, Rails, SQL verbs

Through the use of the new Active Resource framework in Rails 1.2 and the simply RESTful features, Rails provides the ability to map between REST and SQL in a frictionless environment, giving the developer a RESTful architecture with little cost that can be extended and fully used to build custom applications.

When a resource is requested, the actual resource itself is not sent back to the user. Instead, a representation of that resource is sent back, often a web page describing the resource, or an image of it, or an XML document that structures the resource or the outcome of the action performed. This is represented in Figure 6-2.

Figure 6-2. The relationship between identifier, resource, and representation

With Rails, these various resource representations are built on top of controller actions, allowing requests for various forms of resources to share common processing logic. The implementation is abstracted from the services provided.