Chapter 8. Handling Requests with ActionController

Rails is the most well thought-out web development framework I've ever used. And that's in a decade of doing web applications for a living. I've built my own frameworks, helped develop the Servlet API, and have created more than a few web servers from scratch. Nobody has done it like this before.

—James Duncan Davidson, Creator of Tomcat and Ant

ActionController is a key module used by Rails to handle incoming requests by mapping them with, and handing over control to, specific public instance methods known as actions. ActionController works closely with ActionView to formulate a proper response for each request, and together they form a powerful framework known as ActionPack.

The process of going from an incoming request to a complete response that's sent back to the user's browser can be divided into three logical steps: routing the request to determine which action should handle it; executing the code of the action; and finally rendering a template in the view layer. The first two steps are managed by ActionController and, together with testing, are the main subject of this chapter.

When a request comes in, ActionController uses a routing component that looks up the routes defined for the project to determine which controller and action should handle the incoming request. As soon as the controller has been identified, its class is instantiated. The details of the incoming request and a new response object are then passed to its process method (defined by ActionController::Base). This method takes care of extracting the action name from the request parameters, executing the action's code and ultimately disposing of the controller instance when the request-response cycle is complete.

ActionController::Base defines two process methods: a class method and an instance one. The class method acts as a factory that instantiates the controller through the new method, and then invokes the instance method process on it. The instance method is the one that, among other things, actually extracts the action name, executes the action's code, and eventually discards the controller object when a response has been formulated.

All this is possible because you tell ActionController what rules should be used to find the right controller and action. In Rails applications this is typically done in a config outes.rb file. For the blog application, routes.rb was defined as follows (stripped of its many comments):

ActionController::Routing::Routes.draw do |map|
  map.root :controller => "articles"
  map.resources :articles, :has_many => :comments,
                           :collection => { :unpublished => :get }

  map.connect ':controller/:action/:id'
  map.connect ':controller/:action/:id.:format'
end

Any mapping happens within the block passed to ActionController::Routing::Routes.draw. The naming makes sense if you think of it as the process of drawing routes.

Within the block, you employ two types of routings: a RESTful one, which is based on the concept of resource and defined through the method resources, and conventional pattern-matching routing, which is obtained through connect.

resources creates HTTP-verb aware named routes for a collection resource (for example, articles). resources was also the method that provided all the handy *_url and *_path helpers that are based on the named routes. connect, on the other hand, creates an unnamed route only, and this is based solely on two things: the pattern passed as the first parameter (for example, ':controller/:action/:id') and an optional hash of options.

Rails offer maximum flexibility thanks to the fact that within your routes.rb file, you can use one style or the other, or a mix of both. Let's take a speedy look at both routing styles.