This article is excerpted from The Rails Way, published in November, 2007 as part of the Addison-Wesley Professional Ruby Series. Copyright 2008 Pearson Education Inc., all rights reserved. I dreamed a thousand new paths. . . I woke and walked my old one.
—Chinese proverb
The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. And it does a good bit more than that. Rails routing can be a bit of a tough nut to crack. But it turns out that most of the toughness resides in a small number of concepts. After you've got a handle on those, the rest falls into place nicely.
This article introduces you to the principal techniques for defining and manipulating routes.
Many of the examples are based on a small auction application. The examples are kept simple enough that they should be comprehensible on their own. The basic idea is that there are auctions; each auction involves auctioning off an item; there are users; and users submit bids. That's most of it.
The triggering of a controller action is the main event in the life cycle of a connection to a Rails application. So it makes sense that the process by which Rails determines which controller and which action to execute must be very important. That process is embodied in the routing system.
The routing system maps URLs to actions. It does this by applying rules—rules that you specify, using Ruby commands, in the configuration file config/routes.rb. If you don't override the file's default rules, you'll get some reasonable behavior. But it doesn't take much work to write some custom rules and reap the benefits of the flexibility of the routing system.
Moreover, the routing system actually does two things: It maps requests to actions, and it writes URLs for you for use as arguments to methods like link_to, redirect_to, and form_tag. The routing system knows how to turn a visitor's request URL into a controller/action sequence. It also knows how to manufacture URL strings based on your specifications.
When you do this:
<%= link_to "Items", :controller => "items", :action => "list" %>
the routing system provides the following URL to the link_to helper:
http://localhost:3000/items/list<br>
The routing system is thus a powerful, two-way routing complex. It recognizes URLs, routing them appropriately; and it generates URLs, using the routing rules as a template or blueprint for the generated string. We'll keep an eye on both of these important purposes of the routing system as we proceed.
The Two Purposes of Routing
Recognizing URLs is useful because it's how your application decides what it's supposed to do when a particular request comes in:
http://localhost:3000/myrecipes/apples What do we do now?!
Generating URLs is useful because it allows you to use relatively high-level syntax in your view templates and controllers when you need to insert a URL—so you don't have to do this:
<a href="http://localhost:3000/myrecipes/apples">My Apple Recipes</a>
Not much fun having to type this out by hand!
The routing system deals with both of these issues: how to interpret (recognize) a request URL and how to write (generate) a URL. It performs both of these functions based on rules that you provide. The rules are inserted into the file config/routes.rb, using a special syntax. (Actually it's just Ruby program code, but it uses special methods and parameters.)
Each rule—or, to use the more common term, simply each route—includes a pattern string, which will be used both as a template for matching URLs and as a blueprint for writing them. The pattern string contains a mixture of static substrings, forward slashes (it's mimicking URL syntax), and wildcard positional parameters that serve as "receptors" for corresponding values in a URL, for purposes of both recognition and generation.