Datasheet
Chapter 1: Building Resources
6
A RESTful view can also use some logically named methods to generate the URL that you might use
inside a
link_to call in your view. Rather than fussing around with action parameters, or passing the
object or ID you want to control, Rails will automatically respond to methods such as
recipe_path or
edit_recipe_path — assuming, of course, that you ’ ve defined a resource for recipes.
Why REST?
REST is elegant, and I think it ’ s a logical progression of where the best - practices design of Rails
applications has been heading since Rails was released. There ’ s been a continual motion towards having
more controllers, having thinner controllers with the real work done in the model, and enforcing
consistency between controllers. REST provides a framework for moving that design style to the next
level: lots of controllers, lots of activity possible with very little controller code, and absolute consistency
for CRUD - style controllers. If you are the kind of web designer who likes to have the URL interface to
your application be extremely crisp and concise — and many of us are — then REST will feel quite nice.
That said, you ’ re going to see the biggest benefits from REST if your application is either implementing
or consuming web services. The consistency of interfaces to REST resources, coupled with the almost
trivial nature of converting an
ActiveRecord object to an XML representation and back turns every
Rails application into a potential web service, but if you aren ’ t thinking of your application in those
terms, it may not feel like that big of a win. Although you might try to think of your application as a
potential service, it may open avenues of functionality that you haven ’ t thought of before.
Even if you aren ’ t providing a web service, pretty much every Rails application has to do some set of
CRUD actions on its data. REST is a powerful mechanism for making that process even simpler. Again,
though, REST isn ’ t necessarily going to be much assistance in creating the fancy front - end of your
application, but it will make the wiring easier to install, which will leave you more time to make that
front - end even fancier.
Building Your First Resources
Earlier, you saw the initial design for Soups OnLine where two resources, recipe and ingredient, were
described. It ’ s time to put them in your application, using the Rails
generate script. The action for the
script is
scaffold . (In versions of Rails prior to 2.0, it was called scaffold_resource .) The syntax is
simple: the singular name of the resource, followed by pairs of the form
attribute:datatype for each
attribute you want initially placed in the resource.
The data - type portion of each pair can be any type available for use as a data type in a Rails migration:
binary , boolean , date , datetime , decimal , float , integer , string , text , time , and timestamp .
There ’ s no expectation that you have to have the attribute list correct up front (it can always be changed),
but it should just be an easy place to start. The commands and responses look like this (for clarity, I ’ ve
removed lines where Rails shows that a directory already exists):
$ ruby script/generate scaffold recipe title:string servings:string
description:string directions:string
create app/views/recipes
create app/views/recipes/index.html.erb
c01.indd 6c01.indd 6 1/30/08 4:02:22 PM1/30/08 4:02:22 PM