In this third part of an article series on the Action Pack library for Rails, you'll learn about the specialized Action Pack component called routing, and the basic steps of the Action Pack request cycle. This article is excerpted from chapter six of the book Beginning Rails: From Novice to Professional, written by Jeffery Allan Hardy, Cloves Carneiro Jr. and Hampton Catlin (Apress; ISBN: 1590596862).
Action Pack Routing and Request Cycle (Page 1 of 2 )
All the information pertaining to which controller and action to call on comes in the form of the request URL. Action Pack includes a specialized component called routing, which is responsible for dissecting the incoming URL and delegating control to the appropriate controller and action.
Every request that comes into your web application originates in the form of a URL. The routing system allows you to write the rules that govern how each URL is picked apart and handled.
A traditional URL contains the path to a file on the server, relative to the serverís home directory. Hereís an example:
We can tell a lot from this URL. First, we know that the server technology being used is Microsoftís ASP. Given that, we also know that this URL resolves to theshow.aspscript, which is inside the/articlesdirectory. In this case, there is no URL rewriting going on; the mapping of the URL to the script that handles it is one to one.
The problem with this kind of mapping is that the developer has no control over the URL. The URL is coupled to the script. What if you wanted to invoke theshow.aspscript, but wanted the URL to readarticles/detail.aspinstead ofshow.asp? Or better yet, what if you didnít want to expose the underlying script implementation (ASP) at all and use justarticles/detail? There would be no way. The lack of flexibility in this kind of URL mapping is a problem. If you ever need to change the name of the script being invoked, you instantly break all the URL references. This can be a major pain if you need to update all your code, and especially if your pages are indexed by search engines.
Action Packís routing solves this problem by decoupling the URL from the underlying program implementation. In Rails, the URL is related to the specific resource being requested, and it can be formatted to correctly identify that resource without having to conform to the name of script that does the handling. When thought of in this way, URLs become part of the interface of an application, unrelated to the files that are ultimately invoked to process a request.
There are a myriad of reasons why a routing system is a good idea. Here are just a few of them:
Decoupled URLs can convey meaning, becoming part of the interface.
Clean, readable URLs are more user-friendly and easier to remember.
URLs can be changed without affecting the underlying implementation.
The routing pattern used by Rails is actually quite simple and intuitive, and is well demonstrated by the default route:
The first segment of the URL identifies the controller, the second segment identifies the action, and the third identifies a parameter calledid, which will be made available to the controller when the request is handled. Given a URL like the following, we can determine everything we need to know about where in our application the request will be handled:
This URL will be translated into a request for theshowaction on theeventscontroller and be furnished with a single parameter,id, which presumably identifies the event to show. This is a common pattern in web application design, hence its default designation by Rails.
Of course, like most things in Rails, this pattern is open to configuration, and one of the great benefits of routes is that since they are decoupled, they can be customized to create meaningful URLs without much effort. This chapter will teach you how to build and customize routes for your application, how to create named routes, and how to use routes when creating links and redirects in your code.