Rails routing can shock developers who are used to putting their code in files wherever they want to put them. After the directory-based approach of traditional HTML and template-based development, Rails’ highly structured approach looks very strange. Almost nothing, except for a few pieces in the public folder, is anywhere near where its URI might have suggested it was. Of course, this may not be so shocking if you’ve spent a lot of time with other frameworks or blogs—there are many applications that control the meanings of URIs through mechanisms other than the file system.
If you prefer to read “URI” as the older and more familiar URL,
that’s fine. Everything works the same here. (And the core method Rails uses to
generate URIs is, of course,
url_for, in the
Rails routing turns requests to particular URIs into calls to particular controllers and lets you create URIs from within your applications. Its default routing behavior, especially when combined with resource routes generated through scaffolding, is often enough to get you started building an application, but there’s a lot more potential if you’re willing to explore Rails routing more directly. You can create interfaces with memorable (and easily bookmarkable) addresses, arrange related application functionality into clearly identified groups, and much, much more.
Rails 3.0 changes its approach to routing fairly dramatically. While learning what happens in 2.x will still provide a solid ...