3.10 Controller-Only Resources
The word resource has a substantive, noun-like flavor that puts one in mind of database tables and records.However, a REST resource does not have to map directly to an Active Record model. Resources are high-levelabstractions of what’s available through your web application. Database operations just happen to be one ofthe ways that you store and retrieve the data you need to generate representations of resources.
What all of this adds up to is that you might have occasion to create a set of resource routes, and a matchingcontroller, that don’t correspond to any model in your application at all. There’s nothing wrong with afull resource/controller/model stack where everything matches by name. But you may find cases where theresources you’re representing can be encapsulated in a controller but not a model.
An example in the auction application is the sessions controller. Assume a routes.rb file containing this line:
resource :session
It maps the URL /session to a SessionController as a singleton resource, yet there’s no Session model. (By the way, it’s properly defined as a singleton resource because from the user’s perspective there is only one session.)
Why go the RESTful style for authentication? If you think about it, user sessions can be created and destroyed. The creation of a session takes place when a user logs in; when the user logs out, the session is destroyed. The RESTful Rails practice of pairing a new action and view with a create action can be followed! The user login form can be the session-creating form, housed in the template file such as session/new.html.haml
%h1 Login
= form_for :user, url: session_path do |f|
%p
= f.text_field :login %p
= f.label :password
= f.password_field :password
%p
= f.submit "Log in"
When the form is submitted, the input is handled by the create method of the sessions controller:
def create
if user.try(:authorize, params[:user][:password])
flash[:notice] = "Welcome, #{user.first_name}!"
redirect_to home_url
else
flash[:error] = "Login invalid."
redirect_to :action => "new"
end
end
protected
def user
@user ||= User.find_by_login(params[:user][:login])
end
Nothing is written to any database table in this action, but it’s worthy of the name create by virtue of the fact that it creates a session. Furthermore, if you did at some point decide that sessions should be stored in the database, you’d already have a nicely abstracted handling layer.
It pays to remain open-minded, then, about the possibility that CRUD as an action-naming philosophy and CRUD as actual database operations may sometimes occur independently of each other; and the possibility that the resource-handling facilities in Rails might usefully be associated with a controller that has no corresponding model. Creating a session on the server isn’t a REST-compliant practice, since REST mandates stateless transfers of representations of resources. But it’s a good illustration of why, and how, you might make design decisions involving routes and resources that don’t implicate the whole application stack.
Whether sessions are REST-compliant or not depends on the session storage. What REST disallows is not the idea of application state in general, but rather the idea of client state stored in the server.
Sticking to CRUD-like action names is, in general, a good idea. As long as you’re doing lots of creating and destroying anyway, it’s easier to think of a user logging in as the creation of a session, than to come up with a whole new semantic category for it. Rather than the new concept of user logs in, just think of it as a new occurrence of the old concept, session gets created.
