A new pattern for RESTful Rails controllers
The generally accepted pattern for the new/create actions of RESTful Rails controllers goes something like this (using Recipes as the model):
The actions for edit/update are fairly similar so I won't show them here. I've also ignored XML responses as they aren't relevant here.
So what is wrong with this? Lets imagine we're filling out the new recipe form, hence our current path looks like /recipes/new. The form is then posted to /recipes and the @recipe.save call fails due to validation errors in our Recipe model. What is the current path now?
Where we end up is viewing the same form previously accessed at /recipes/new, but now at the path /recipes. Having two URLs accessing the same view, whilst not a major cause for alarm, emits an unpleasant odor.
In recent projects, I have taken to the following alternative pattern:
The changes are small but we are now using the session to store the invalid object. If the object fails to save, we redirect back to the new recipe form (at the correct path /recipes/new), which attempts to load the recipe from the session, otherwise defaulting to the original behavior.
Using the session in this way has one big drawback -- we can no longer reliably use the default Rails cookie session store. There are two main reasons for this: a) Cookie stores have a storage limit of 4k, which can easily be reached when storing large objects in the session -- you'll end up with CookieOverflow exceptions being thrown; and b) Saving an object in the cookie store sends the entire object to the client, potentially exposing hidden data. Because of this, I choose to use the memcached session store (which is almost trivially easy to set up unless you're on a shared host).
This approach also appears to add some complexity, but in some ways its behavior is clearer. Consider the case in the original example where we want to add an error message to the flash:
BZZZT! What we actually need to use here is flash.now[:error] rather than flash[:error] because we want to render the error within the same action. This gotcha doesn't exist in my alternative version.
So what do you think? Are there any use cases apart from those mentioned where this is either going to fail or cause security issues? Is it even worth using this pattern to fix the original problem, despite the caveats? I think so but I'm willing to be proven wrong.
