Question

I’m writing an app that has a “wizard” type input section. Think MS Windows Installers.

I’m having a hard time figuring out how the most RESTful way to do this with rails. I can make it happen in a non-restful way (already did for version 1 of the app), but I’m trying to be a little more idiomatic this time around.

Here’s the situation. I have a 5 step wizard that has to gather information. Steps 1, 2, and 4 deal with resource A. Step 3 deals with multiples of resource B and must associate them to resource A. Step 5 is just a confirmation.

So I have my resourceA_controller and my resourceB_controller…but they only save/update that one resource. I’m guessing that I should set up a wizard_controller for each of the steps in the process, but I’m not sure how the routing should work.

For example…

WizardController < ApplicationController
  def stepOne
    @resourceA = ResourceA.new
  end
  def stepTwo
    @resourceA = params[:id]
  end
  ...
  def stepFive
  end
end

And then I would have my view be on the StepOne view:

<form action='/resourceA/new'/>

and on the StepTwo action

<form action='/resourceA/12345/edit'/>

etc.

But then my resourceA and resourceB controllers would have to know how to redirect to the appropriate step in the wizard_controller. Tangled mess!

Am I anywhere near the right track? Or is there a rails built-in mechanism or plugin that does this kind of thing.

Answer 1

It’s important to understand the distinction between what REST provides and what REST doesn’t care about.

• A RESTful service provides a minimal set of actions which a client can use (providing it knows the correct data format) to manipulate a class of resources

  • For example, you should be able to POST to /resourceA/12345 to edit that existing resource

• A RESTful service doesn’t make any guarantees about which other URLs will return meaningful responses.

  • One notable example is that REST doesn’t specify that /resourceA/12345/edit will return an HTML form designed for editing that resource. That’s a feature of the HTML application that simply provides a method of performing the POST described above.

  • Extending this theory, it’s perfectly acceptable to have multiple edit forms which all POST to the defined RESTful URL. Since the controller’s edit action will generally use .attributes = ... to mass-assign whatever it’s passed, you can look at the attributes passed in, along with information about which HTML button was used to submit the form, to decide which page the user should see next.

  • It may be scary relying on one controller method to deal with multiple page’s submissions, but with clever validation and selectively overwriting accessors, you can maintain a lot of control over how users access the app.

  • You should also be able to work out that this method doesn’t restrict users to only sending attributes in the order presented in the form. Another RESTful client could in theory POST updates for all attributes associated with a resource, rather than just those presented by one page of your wizard. Assuming your model methods are robust enough everything can be made to Just Work.