MVC, REST, and the Alternative ASP.NET Framework

Phil and Dino Esposito have been talking about the RESTful aspects of the upcoming ASP.NET MVC framework.

REST – It's All About the Resources

You can read about REST in a PhD thesis, but I think Tonic captures the essence of a RESTful architectural style from the perspective of a web application developer:

• Everything useful is a resource, not a file, not a CGI script, a resource, an abstract concept of something useful that the client wants to grab hold of.
• Resources are located by URLs, URLs are cheap and form the universal addressing system of the Web.
• Clients can issue a standard number of HTTP methods upon an infinite number of resources and receive something useful in return.
• Representations of resources are sent back to the client, a representation is just a way of turning the abstract concept of a resource into something more concrete, like a HTML page or a XML file. One resource can have many different representations.

One could treat each customer of the company as a resource. Locating a customer is as easy as formulating the proper URL, while the standard HTTP verbs (GET, POST, PUT, DELETE) will identify what sort of operation we wish to perform. Witness an URL like:

http://Astoria/northwind /Customers[ALFKI]

This is what we'll see in ADO.NET Data Services (Astoria).

Proponents of REST (the RESTafarians) have made a lot of noise over the last few years in the SOA and WS-* space. Why? In short because SOAP and the WS-* standards are now large bodies of work that spawn large toolsets – not everyone wants or needs the complexity.

Not Just For CRUDdy Data Services

When building a web site, we don't debate the merits of RPC versus REST, but we do debate the merits of friendly, hackable, and predictable URLs (like https://odetocode.com/articles/aspnetmvc/) versus scary, opaque, and unanticipated URLs (like https://odetocode.com/articles.aspx?c=5F9C-2FZ). We say the friendly URL is RESTful –while the other URL is still just scary.

REST has a place in web applications then, and not just in data services. However, I don't think we want to start our web applications with a resource modeling session.

Besides – I think friendly URLs are a byproduct of the new framework, and not, as Dino hints, its raison d'être.

The C Is For Control

In traditional web forms, ASP.NET maps incoming requests to the file system. Employee.aspx, for example, is a form we could use to list employees, update employees, delete employees, and create new employees. Employee.aspx is both the view (aspx) and the controller (code-behind) - and the two are inexorably bound.

The catch is that the "controller" does not have control in this scenario. The controller is tightly coupled to a single view - and can only act in response to the view's lifecycle events. The "view as addressable resource" model just doesn't work for MVC, no matter how you spin the story.

The MVC framework is, I believe, about putting control in the hands of a web developer. Control over the routing of HTTP requests to components. Control over selecting the view. Control over state management, and control over the outgoing HTML. Breaking the "one URL for every view" paradigm is necessary for MVC, and coincidently gives a developer total control over the addressable resources in an application.

In other words - RESTful URLs are possible because the framework uses a true MVC model, and not vice-versa.