When should you use RESTful controllers in a Rails app, and when should you not?

Question

I'm looking for guidelines on when to know when a RESTful approach to a model and it's associations is proper, and when it's not. Perhaps it's the nature of my current application, but I'm finding that simple models with no associations work well with REST, but complex models with many has_many assocations really seem to complicate the view and the setup required in the controller. form_for calls start to become especially complicated.

Or perhaps it's my neophyte understanding. I've been doing Rails for over three years now, but REST and form helpers together seem to mystify me.

Answer 1

I don't know RoR, so I will make generate statements on REST.

REST and ROI treats the URLs as series of nouns, and it uses HTTP methods like GET, POST, PUT, and DELETE as the verbs. This model works for CRUD, and even for models with multiple associations. Since URLs represent resources, associated objects can be expressed as list of URLs.

However if your system requires more fine-grain verbs like validate, move, copy, honk, read, write etc. it may not suit REST.

Answer 2

disclaimer: I know rails, but I still am pretty much a newbie. Short Answer: REST and form helpers are completely different areas.

Long answer: As I understand it,Representational State Transfer is only loosely related to the actual rendering of forms and views.

REST really has to do with controllers, and to a certain extend models. The idea is that instead of trying to think about an entire conversation with a client, you write a webapp to respond in specific, predictable ways to individual client messages.

i.e., if a client GETs a model, you just retrieve it, format it for them, send it to them, and forget about it. if a client POSTS an update of some sort, you change the webapps state to reflect that, send back any response, and then forget about it. Any future GET or POST will look at the new state, but not the message that created it.

So, really, whether or not an application is RESTful depends not really on how complicated the model is, but on how users interact with it. An app meant to be at least somewhat client-agnostic, that is data-centric, is a good candidate for REST. Something that relies heavily on sessions, and interacting with a specific user, and is process-centric, might not be such a good candidate.

On the other hand, you have Rails form helpers. These are great for scaffolding, but sometimes can be frustrating when you try to use them in more complicated ways.

So, what is your main question? Do you have a specific question about rails form helpers? about rails controllers? or something specific to REST?

Answer 3

Make a resource of each top-level model in your system. By top-level, I mean models that are independent and have meaning outside of the associated model. Generally, that's most models. In the following example Position and Candidate are top-level. You could consider Candidate to be composed of PastEmployment and positions to which she has applied. Applications to positions and prior work history can be accessed through the Candidate resource, since they don't exist on their own.

Models

class Position
  has_many :candidate_positions
  has_many :candidates, :through => :candidate_positions
end

class Candidate
  has_many :candidate_positions
  has_many :positions, :through => :candidate_positions
  has_many :past_employments
  accepts_nested_attributes_for :past_employments
  accepts_nested_attributes_for :candidate_positions
end

class PastEmployment
  belongs_to :candidate
end

class CandidatePosition
  belongs_to :candidate
  belongs_to :position
end

Routes

map.resources :positions
map.resources :candidates

Use a non-resourceful controller for interactions with the user that span models. For example, if you wanted to have a HomeController that shows available positions as well as recent candidates, that would be a new, plain controller. If you want to edit any of the information on this controller, cool! You already have controllers available to handle the form posts, that will automatically be wired with <% form_for @candidate %>. You can render your collection of positions with <%= render @positions %>, and because you've made them a resource, Rails will know to look in views/positions/_position.html.erb for the appropriate partial.

The end result should be that you're never writing logic to handle the persistence of an object in more than one place. That's when controllers get complex and forms get out of hand. It also means that Rails and external systems know where to retrieve and store objects. Same URL, same controller, just a different format.

Answer 4

You might check out this series of Railscasts, which talks about has-many relationships and forms in the context of REST:

• Complex Forms Part 1
• Complex Forms Part 2
• Complex Forms Part 3