I’m migrating one of my main e-commerce sites from php to Rails. Coming from a few years of Java and php makes me really appreciate this framework’s rapid development cycles, as well as strict MVC approach.

Note: this is a technical post, it assumes you’re interested in, and familiar with Rails.

Rails wants to be RESTful. Many sites and books go into depth explaining REST. Last year’s Railsconf keynote by DHH can give you the big picture of CRUD and RESTful applications. (Be sure to follow along with the pdf slides, while you watch the video).

Look at an existing mature project (Beast) to learn how to make RESTful models

Nitty gritty RESTful implementation details have been hard to find. So I started searching out open source projects that are known for good design. And I read the code.

Beast is a forum program written in Rails by Rick Olson and Josh Goebel. Best of all, it’s a great example of a REST application.

I’m a visual person, so I created the chart below to help me get the hang of what the Models and relationships look like in Beast. Big bold squares are actual database backed objects. Dotted squares are just regular models.

Please contact me if you catch an error or omission.

Here’s how you use the diagram

Right now, browse here: http://svn.techno-weenie.net/projects/beast/trunk/app/models to the Subversion source of Beast. Back already? My you’re fast. Read over the different model objects. See how they relate. Think about what’s been abstracted into additional Resources, rather than creating actions willy nilly in the controllers.

Then check it out and run it in your local environment. Even if you couldn’t care less about the (quite nice) forum software that it is, it’s good to learn by taking it for a spin.

But I think I need more actions than CRUD gives me!

As DHH said in the 2006 Railsconf keynote, sometimes you think you need another non-CRUD verb to your controller. Say you have a Forum that has Users and Topics. Some users want to monitor topics. At first blush, you may want to add an action to Topic. You’d then post to /topic/monitor/123 to start monitoring topic 123.

There is another way.

Relationships, events and states can all be models. When a new topic is to be monitored, you’ll GET to /monitorships/new to get the new Monitorship object form. Then POST to /monitorships to actually create it.

Models are more than things.