Action <a href="/rails/Controllers">Controllers</a>
are the core of a web request in Rails. They are
made up of one or more actions that are executed on request and then either
render a template or
redirect to another action. An action is defined as a public method on the
controller, which will automatically be made accessible to the web-server
through <a href="/rails/Rails">Rails</a> Routes.

Actions, by default, render a template in the
app/views directory corresponding to the name of the controller
and action after executing code in the action. For example, the
index action of the GuestBookController would render the template
app/views/guestbook/index.erb by default after populating the
@entries instance variable.

Unlike index, the sign action will not render a template. After
performing its main purpose (creating a new entry in the guest book), it
initiates a redirect instead. This redirect works by returning an external
"302 Moved" HTTP response that takes the user to the index
action.

The index and sign represent the two basic action archetypes used in Action
<a href="/rails/Controllers">Controllers</a>.
Get-and-show and do-and-redirect. Most actions are variations of these
themes.

Requests

Requests are processed by the Action
Controller framework by extracting the value of the "action"
key in the request parameters. This value should hold the name of the
action to be performed. Once the action has been identified, the remaining
request parameters, the session (if one is available), and the full request
with all the HTTP headers are made available to the action through instance
variables. Then the action is performed.

The full request object is available with the request accessor and is
primarily used to query for HTTP headers. These queries are made by
accessing the environment hash, like this:

Parameters

All request parameters, whether they come from a GET or POST request, or
from the URL, are available through the params method which returns a hash.
For example, an action that was performed through
/weblog/list?category=All&limit=5 will include {
"category" => "All", "limit" => 5
} in params.

It’s also possible to construct multi-dimensional parameter hashes by
specifying keys using brackets, such as:

A request stemming from a form holding these inputs will include {
"post" => { "name" => "david",
"address" => "hyacintvej" } }. If the address
input had been named "post[address][street]", the params would
have included { "post" => { "address" => {
"street" => "hyacintvej" } } }. There’s
no limit to the depth of the nesting.

Sessions

Sessions allows you to store objects in between requests. This is useful
for objects that are not yet ready to be persisted, such as a Signup object
constructed in a multi-paged process, or objects that don’t change
much and are needed all the time, such as a User object for a system that
requires login. The session should not be used, however, as a cache for
objects where it’s likely they could be changed unknowingly.
It’s usually too much work to keep it all synchronized —
something databases already excel at.

You can place objects in the session by using the session method,
which accesses a hash:

Sessions are stored by default in a browser cookie that’s
cryptographically signed, but unencrypted. This prevents the user from
tampering with the session but also allows him to see its contents.

Do not put secret information in cookie-based sessions!

Other options for session storage are:

ActiveRecordStore - Sessions are stored in your database, which works
better than PStore with multiple app servers and, unlike CookieStore, hides
your session contents from the user. To use ActiveRecordStore, set

config.action_controller.session_store=:active_record_store

in your config/environment.rb and run rake
db:sessions:create.

MemCacheStore - Sessions are stored as entries in your memcached cache. Set
the session store type in config/environment.rb:

config.action_controller.session_store=:mem_cache_store

This assumes that memcached has been installed and configured properly. See
the MemCacheStore docs for more information.

Responses

Each action results in a response, which holds the headers and document to
be sent to the user’s browser. The actual response object is
generated automatically through the use of renders and redirects and
requires no user intervention.

Renders

Action Controller sends content
to the user by using one of five rendering methods. The most versatile and
common is the rendering of a template. Included in the Action Pack is the
Action View, which enables rendering
of ERb templates. It’s automatically configured. The controller
passes objects to the view by assigning instance variables:

Redirects

Redirects are used to move from one action to another. For example, after a
create action, which stores a blog entry to a database, we might
like to show the user the new entry. Because we’re following good DRY
principles (Don’t Repeat Yourself), we’re going to reuse (and
redirect to) a show action that we’ll assume has already
been created. The code might look like this:

When building a REST server which should accept YAML there are several things to take into
consideration.

First of the client should tell the server what type of data it is going to
send. This is done via the Content-Type header (which is NOT only a response header as opposed
to what the RESTful Web Services book from O’Reilly made us believe).

Second the server application should know how handle the body of the POST
request. Placing the
following line in your environment.rb: