1.3. The REST of the Story
I pledge right now that will be the only REST-related pun in the whole book (unless I think of a really good one later on).
REST is another one of those tortured software acronyms — it stands for REpresentational State Transfer. The basic idea dates back to the doctoral dissertation of Ray Fielding, written in 2000, although it only started gaining traction in the Rails world in early 2006, when a couple of different plugins allowed for a RESTful style within Rails. The functionality was rapidly moved to the Rails core and has just as quickly become a very commonly used practice, especially for standard Create, Read, Update, Delete (CRUD) style functionality.
1.3.1. What Is REST?
There are three different ways of thinking about REST as compared to a traditional Rails application:
Pages versus resources
Network protocols
Rails features
You'll explore each of these in the following sections.
1.3.1.1. Pages versus Resources
The traditional view of data on the Web is action-oriented. A user performs an action on a page, usually by just accessing the page, but sometimes by sending data as well. The server responds with data, usually in HTML, but a pure web service is likely to send XML or JSON.
A RESTful application, in contrast, is viewed as a set of resources, each of which contains some data and exposes a set of functions to the Web. The core of these functions is made up of the standard CRUD actions, and the application programming interface (API) for the standard functions is supposed to be completely consistent between resources. A resource can also define additional actions for itself.
If this reminds you of the distinction between procedural programming and object-oriented programming (OOP), with REST resources playing the part of objects, well then you've got the gist. One difference is that using REST in Rails primarily changes the way in which the user accesses your data because it changes the URL structure of your site, but the data itself will be largely unaffected, whereas an object-oriented design does affect the way your data itself is structured.
1.3.1.2. Network Protocols
The signature feature of a REST-based web application is the use of HTTP access methods as critical data when determining what to do in response to a request. HTTP defines four different methods for requesting data (and eight methods overall). Many of us learned this fact in a beginning HTTP book or network course and promptly filed the information under "trivia that might win a bet someday, in a bizarre set of circumstances." Only two of these methods are in general use — nearly every server since the days of Mosaic has only used GET for getting information out of the server and POST for putting information into the server. In addition, most web applications used separate URLs for their GET and POST operations, even where it was technically feasible to share URLs. For example, the Java Servlet specification allows the same servlet to respond differently to a GET or POST, but all of the servlets I've written either defined one of the methods as a clone of the other, or only respond to one method, ignoring or failing if the other is invoked.
It turns out, though, that the HTTP protocol also defines PUT and DELETE. It's easy to understand DELETE, but it's not immediately clear what the original intention was for the distinction between PUT and POST — you'll see in a second the distinction REST and Rails make between them. A RESTful application uses all of these methods (often called verbs) as a meaningful part of the Web action. In other words, when confronted with a URL like http://www.soupsonline.com/recipes/1, a RESTful Rails application cannot determine what controller action to perform without knowing whether the request was a GET, DELETE, or PUT. A GET request would result in a show action, the DELETE request triggers the delete action, and the PUT request triggers the update action. In contrast, a traditional Rails application would have the controller action explicitly specified in the URL, ignoring the HTTP verb. The traditional URL might look like http://www.soupsonline.com/recipes/show/1 or http://www.soupsonline.com/recipes/update/1. (I realize that it' s slightly absurd to refer to anything in Rails as traditional, but there isn' t a better retronym for the non-REST applications.)
By now, you may have realized a contradiction that I've hand-waved my way past. If all the browsers handle only GET and POST, then how does a RESTful Rails application use PUT and DELETE? The Rails core team, like geniuses since time immemorial, is not going to let a little thing like the imperfection of the current state of browsers get in the way of a conceptually nifty idea like REST. When you ask Rails to create a PUT or DELETE link, it actually wraps the request inside a small POST form with a hidden field that Rails then decodes on the server end. In the happier RESTful future, servers will implement the complete HTTP specification, and Rails can dispense with the disguise and display its PUTs and DELETEs proudly.
1.3.1.3. Rails Features
Within Rails, you do not explicitly define a class called a Resource in the same way that you explicitly define Controller or Model classes — at least, not for resources controlled by the local Rails application (see Chapter 9 for how you might access resources from a remote server). A resource emerges from the interaction of a Controller and a Model, with some magic in the route-mapping gluing them together. Although Rails provides a REST resource generator that creates a tightly coupled Controller and Model, you could easily have two separate resources managing different facets of a model. Each resource would have a separate controller. For instance, if you had some kind of employee database, you could manage contact information and say, vacation days as separate resources with separate controllers, even though they are in the same model. As you'll see in just a few moments, you can also nest resources, designating one resource as the parent of another.
RESTful resources also bring along some helpful nuts-and-bolts functionality that makes them quite easy to deal with. The controller method respond_to was created for REST (although it can be used in any Rails controller), and makes it extremely easy to deliver your data in multiple formats. Continuing the description in the previous section, using respond_to, your application can return different data for the URL http://www.soupsonline.com/recipes/1.png.
A RESTful view can also use some logically named methods to generate the URL that you might use inside a link_to call in your view. Rather than fussing around with action parameters, or passing the object or ID you want to control, Rails will automatically respond to methods such as recipe_path or edit_recipe_path — assuming, of course, that you've defined a resource for recipes.
1.3.2. Why REST?
REST is elegant, and I think it's a logical progression of where the best-practices design of Rails applications has been heading since Rails was released. There's been a continual motion towards having more controllers, having thinner controllers with the real work done in the model, and enforcing consistency between controllers. REST provides a framework for moving that design style to the next level: lots of controllers, lots of activity possible with very little controller code, and absolute consistency for CRUD-style controllers. If you are the kind of web designer who likes to have the URL interface to your application be extremely crisp and concise — and many of us are — then REST will feel quite nice.
That said, you're going to see the biggest benefits from REST if your application is either implementing or consuming web services. The consistency of interfaces to REST resources, coupled with the almost trivial nature of converting an ActiveRecord object to an XML representation and back turns every Rails application into a potential web service, but if you aren't thinking of your application in those terms, it may not feel like that big of a win. Although you might try to think of your application as a potential service, it may open avenues of functionality that you haven't thought of before.
Even if you aren't providing a web service, pretty much every Rails application has to do some set of CRUD actions on its data. REST is a powerful mechanism for making that process even simpler. Again, though, REST isn't necessarily going to be much assistance in creating the fancy front-end of your application, but it will make the wiring easier to install, which will leave you more time to make that front-end even fancier.