I have moved my active blog over to tumblr. I've maintained this blog for reference but will be posting to http://www.robustsoftware.co.uk instead. I've pointed my Feedburner feed to tumblr so if you're subscribed already you should already have switched with me.

Overloading POST – a change of mind

Today I made a fairly fundamental change in design of RESTful ASP.NET MVC revolving around how I will be overloading post for HTML forms.

Previously I was adding a hidden field to the form, which is how it is done by Rails:

<form method="POST" action="/Users/2">
<input value="DELETE" type="hidden" name="_method" />
<input value="Delete" type="submit" />
</form>

I was aware of OpenRasta's method of overloading post which is to append the overload to the URI:

<form method="POST" action="/Users/2!DELETE">
<input value="Delete" type="submit" />
</form>

However, I didn’t like the way the overload was opaque to the user and thinking that the Rails guys must have thought about it a fair bit I initially went with the former method.

I ended up having a discussion with Sebastien Lambla, the developer of OpenRasta, about the two options and why he had chosen the second method over the first (I love twitter for this). To be honest, I came away from the discussion thinking there wasn’t much to chose between the two, it just being down to a matter of preference. However, I kept thinking about it, questioning my decision and whether it my choice really was better than the other option.

I had a moment of clarity whilst playing golf. I realised that, potentially, I might have to write post overload mechanisms for multiple formats as clients could submit requests in a variety of formats (XML, JSON, form, etc). If the overload is contained within the URL then the overload is independent of the body’s content type, simplifying things considerably.

Now I had a reason to change, I did so, changing RESTful ASP.NET MVC’s method of overloading post to the URI mechanism. As it happens this tidied up the code a little as I no longer had to pass around the form collection, I could work purely off the routing values.

Related posts:

You should subscribe to my feed to keep up with development of RESTful ASP.NET MVC.

UPDATE

I have written a follow-up post about the implementation considerations for POST overload that I recommend reading as well.