Simply RESTful… "The missing action"

UPDATE 15/03/10: The debate continues…

The ideas in this article came about whilst I was test-driving the Simply RESTful plugin following DHH’s RailsConf keynote on the subject.

The philosophy

The first thing I came across whilst experimenting with Simply RESTful (which is great by the way), was that there is no real way of deleting items with javascript disabled. Since I am currently working on a project that needs to function on a variety of mobile devices, this instantly caused me concern.

I could think of a few ways to hack around this limitation, however I was sure there had to be a better way, hence this article. I wanted to keep the current javascript functionality but in addition have a clean non-javascript fallback.

Consider the following:

CRUD Form (GET request) POST action
(C)reate /products/new create
(R)ead /products/24 n/a
(U)pdate /products/24/edit update
(D)elete destroy

There are three “state changing” actions in CRUD, they are the ‘create’, ‘update’ and ‘delete’. You will notice from the table above that all three have a POST action1, however only two have GET actions… why is this?

Now, you see that dash in the second column… that’s “the missing action”. There is no good reason why our ‘destroy’ action shouldn’t have a corresponding form action (GET request) also. Let me explain myself…

1 The HTTP actions are PUT, POST and DELETE, however in this implementation (due to the limitations of HTML) they are all technically POST’s.

Putting it into practice

So we give ‘destroy’ it’s missing action which will act as a confirmation of our post… and what shall we call this missing action? …why let’s call it delete.

If we fill in this missing piece in our RESTful Rails puzzle, all becomes clear:

CRUD Form (GET request) POST action
(C)reate /products/new create
(R)ead /products/24 n/a
(U)pdate /products/24/edit update
(D)elete /products/24/delete destroy

Our routes would look something like:

map.resource :product, :member => { :delete => :get }</pre>
In our controller would be:
<pre lang="ruby">def delete
  @product = Product.find(params[:id])
def destroy
  Product.find(params[:id]).destroy if request.delete?
  redirect_to product_url

Our delete.rhtml would look like this:
<pre><h1>Are you sure you wish to delete ?</h1></pre>

Slight complication…

Update (13 Oct 2007): This has been fixed in more recent versions or Rails.

Now comes the slight complication… we want the javascript POST to /projects/24 to function as normal, however if javascript is disabled we want to request /projects/24;delete.

Wouldn’t it be nice if you could specify a fallback (non-javascript) href in the link_to helper, something that I’ve pondered with on many occasions. Unfortunately the link_to helper doesn’t let you override the href attribute (currently it adds a second one instead), until now.

Enter iq_noscript_friendly plugin which fixes this shortfall (I also have this as a Rails patch however the ticketing system on Trac is currently broken).

Install the plugin using:

./script/plugin install

In our listing view (index.rhtml) we are now able to do the following:

link_to 'Delete', product_url(product),
          :confirm => 'Are you sure?',
          :method => 'delete',
          :href => delete_product_url(product)

Ideally you would just give the link a class of “delete” and use unobtrusive javascript to make it do the delete request.



By adding “the missing action”, we are able to POST as usual (using javascript) to ‘destroy’ but gracefully fallback to our ‘delete’ form when javascript is not available. Besides, why shouldn’t ‘destroy’ get it’s own form action… ‘create’ has ‘new’ and ‘update’ has ‘edit’?

Now to make this whole thing even better, lets make it part of the convention. ‘delete’ should default to GET and therefore negate the need for :member => { :delete => :get } in our routes.rb… DHH?

I would love to hear peoples comments on this technique as I’m using it for everything now and it works a treat.

Com’on… use “the missing action”, be kind to those without javascript, and lets make it the convention!

Rock on RESTfulness.

Join the conversation


  1. Having a delete and destroy is just confusing. I usually do something like this:

    def destroy
      if request.delete?
        redirect_to foos_url
  2. rick: You are missing my point, what if you have javascript turned off? You need an action to POST from i.e. a “confim delete” form.
    Sure you could put this in the same action but I don’t think it belongs there.
    Request deletion -> Confirm deletion -> Destroy
    Just like edit:
    Request edit -> Confirm changes -> Update

  3. @/people/1;delete@ falls right in line with the other two pre-action forms. (@/people;new@ & @/people;edit@)
    However, if you think of the pre-action forms (new & edit) as merely a way to define the parameters of the action. _(name, password, etc…)_ Then it doesn’t really work for delete _(or show, for that matter)_. Do you need parameters for the delete or show actions (other than the id)?
    But, if you think about it from a fallback point of view, it works. You might want to do in-page AJAX fanciness for new, edit & delete. Then fall back to the actual pages if you can’t do the fanciness. (Yes, I’m including the javascript confirm as in-page fanciness.)
    I totally agree that this should be the default implementation.

  4. I hate to rain on your parade, but HTTP GET requests are not supposed to change the server’s state. Deleting an item is most certainly a change of state, so that is why DELETE has no GET url.

  5. *@rcb*
    The delete action is a _confirmation_ of deletion. I don’t think anyone here is advocating deleting records via GET.
    The delete action’s view holds the submission form which acts as a gateway to the destructive operation.
    Make sense?

  6. rcd: I am not suggesting you call destroy via a GET as you are right that would be bad.
    Rabbit is right, it is simply a “request” to “delete” which gives you a form that then posts to “destroy”, just as “new” is a post to “create” and “edit” is a post to “update”.

  7. I think you misunderstood Rick. He’s doing it the better way. Just rename delete.rhtml to destroy.rhtml and it will render that unless it’s a DELETE request. So, when the form in destroy.rhtml or the JavaScript sends the DELETE request to the same URL it will delete the record and redirect to foos_url.

  8. Tristan: That would work if you weren’t using simply restful, however with simply restful the destroy url is the same as the show url, just with a different method set.
    If you fall back to /products/24 when javascript is disabled you will just get the show page as the routes have no way of telling that you wanted destroy. That is why the fallback url needs to be different i.e. /products/24;delete, you can then POST to destroy with method set to delete and the routes know what you want.
    Make sense?

  9. Thomas: Sorry, my reply you your comment got lost.
    In response to:
    bq. “However, if you think of the pre-action forms (new & edit) as merely a way to define the parameters of the action. Then it doesn’t really work for delete (or show, for that matter). Do you need parameters for the delete or show actions (other than the id)?”
    There may be occasions when you want to e.g. log a reason for deletion etc. That is what Iove about this method, it caters for many scenarios.

  10. You got me there. Luckily, this is Rails and we can do whatever we want.
    First, drop in my handy dandy hack that allows you to use arrays for method requirements: It looks like a lot, but I assure you it’s only an additional 12 lines consisting mostly of if statements.

    def destroy
      if request.delete?
        respond_to do |type|
          type.html { redirect_to('/') }
          type.js   { render(:update) { |page| page.redirect_to('/') } }
    map.resources :users
    map.resources :users, :member => {:destroy => [:delete, :get]}
    You could also use an AJAX link here, but this way requires you to always
    confirm it.
      Cancel Account

    I obviously take arguing too seriously, but boy did I get rid of that extra action. Maybe it’ll even make it to the core one day, but I doubt it.
    By the way, this was my first core modification.

  11. FYI, I’m running into a problem in testing with a destroy action in another controller. Not sure if it’s related, but I’m going to guess and say it is.

  12. Tristan: I really think you are over complicating things.
    Why are you so keen to get rid of the extra action in favour of a load of conditional code?
    * update has edit
    * create has new
    * why shouldn’t destroy have delete?
    I would much rather have one extra action and do away with all the conditional stuff and hacks.

  13. I guess I was just looking for an excuse to make a hack. That or the fact that I’ve only had 6 hours of sleep in the past 41 hours. I see what your getting at with the other actions, and for some reason it only makes sense now that you pointed it out. I think I’ll go to sleep before I write more useless modifications for Rails.

  14. Tristan: “Stop worrying and learn to love the delete” 😉
    Have you had any luck submitting tickets to Rails Trac site? I keep getting an error.

  15. I arrived here from Railscast #205. I’m a relative newcomer, but I arrived at the same conclusion that you did: there’s a missing method. But I described it slightly differently:
    The contract of #new (idempotent method) is to render a GUI element that, when submitted, calls #create (non-idempotent method) to actually create the object.
    The contract of #edit (idempotent) is to render a GUI element that, when submitted, calls #update (non-idempotent) to update the object.
    The #delete method lacks the corresponding idempotent / non-idempotent pairing. There should be an idempotent method whose contract is to render a GUI element. Submitting that element should call #delete to actually delete the element.
    I submitted this as a lighthouse comment a while back:
    FWIW, josevalim closed it with the comment that it would make a good plugin.

Leave a comment

Your e-mail address will not be published. Required fields are marked *