A little while back I reviewed the Rest for ASP.NET MVC SDK that was released by Microsoft WCF team. I liked some of the ideas it contained so promised to bring some of those into our code. Well, I’ve finally started to do that.

I have been doing most of my ASP.Net MVC RESTful web service development on IIS6 or IIS7. Recently however, I tried it on Windows 7 RTM using IIS7.5. Using the “Classic .Net AppPool” everything worked great. Then I tried the “DefaultAppPool” (i.e. using Integrated Mode). Everything seemed fine… until I wanted to PUT a new resource and DELETE a resource.

Over the last year I written a whole series of articles looking at creating a RESTful web service. For some time I’ve been meaning to tidy up the DLL that provides the RESTful functionality… and finally I’ve got round to it!

In my last post I created a wizard using the basic ASP.Net MVC 1. That version of the wizard reduced the Controller’s knowledge of the View to the bare minimum required. In this post I want to try to get the same functionality using the Data Annotations Model Binder Sample. My hope was that using Data Annotations, rather than hand crafted validation, would reduce the need for the controller to understand the details of the model.

Over the last few weeks I have been creating a new web site using ASP.Net MVC. One area I was unsure as to how to approach was account registration. The default project creates a simple account registration page, but I wanted something more complex… more like a wizard.

A few days ago, a Rest for ASP.NET MVC SDK was released by the WCF team onto CodePlex. I spotted this very low key release after it was mentioned on Phil Haack’s blog. He asks for feedback on the ideas in the SDK and samples, as many of them are being considered for future releases of the main ASP.Net MVC. So after an initial tyre kicking, I thought I’d look at how hard it would be to migrate my web service to this SDK, what would be the benefits and would I have to make any compromises.

At the end of my last post about adding connectedness to our web service I had added support for XHTML and XML representations. This allowed us to inject URIs into the representation without changing our Model classes. This was relatively simple because, for those representations, we had stuck to the principle introduced in Multiple Representations of having a transformation layer between internal and external representations of our entities. In this post I want to tackle JSON representations.

In their book RESTful Web Services, Leonard Richardson and Sam Ruby take Roy Fielding’s phrase ”hypermedia as the engine of application state” and explain that it means that the responsibility for tracking and changing application state lies with the client rather than the server. The server indicates how the client can change the application state by providing URIs that point to other possible states. The phrase they prefer to use in place of Roy Fielding’s phrase is “Connectedness.”

In this entry I would like to round up where we have got to so far with this web service. Over the last 13 posts we have developed a fairly functional web service that sticks pretty much to the ideas presented in Leonard Richardson and Sam Ruby’s book RESTful Web Services. It is developed using C# using the (currently Beta) MVC framework from Microsoft that extends the ASP.Net framework.

As an aside, I’ve also taken on board a comment from Stephan and moved some of the reusable classes into their own assembly.

Now we can create a resource from an incoming XHTML representation, it is time to accept a representation of a new resource via an HTTP POST. This should be pretty much the same as accepting a new resource via an HTTP PUT.

So what is the difference between a PUT request and a POST request? A PUT request is made directly to the URI of the new resource, the client dictates the URI. A POST request is made to the URI of the new resource’s “parent” URI, the server decides on the full URI of new resource.