SerialSeb
Using Rasta #1 - An introduction
Rasta has many meanings, but for the purpose of this blog, it is the REST Architecture Solution Targeting Asp.net. I've written this framework for one of my clients, and I'm in the process of trying to get the rights to open-source it and deliver it to the world. But as many things, it takes a lot of time.
That said, I've been wanting to blog about it since I started working on it, so now is as good a time as ever to start showing some bits on how to use it. It will let my beloved readers criticize the way the API is built, which will let me involve it for the better, and will also serve as a reference point for my client's employees to have some sort of reference on how the framework works.
Rasta, in essence, is a framework that lets you think about your site in terms of resources, how they are accessed, and how representations of such resources get served to clients. Let's compare this approach with other approaches we've seen over the years.
WebFroms
In this model, your Url is bound to your page. Because of the post-back model, any interaction with the system is done as units within the webform. http://example.org/Customer.aspx provides a view of your customer, but is also where data gets posted back. The posting of the data itself can be either about a customer, or about a button, or about an event one of the webcontrols can trigger. It can be a bit of anything.
This has a couple of very bad consequences. Only the asp.net framework can post data to /customer.aspx, because it's the only one knowing the format. This makes testing webforms terribly difficult, and patterns like MVP only solve the problem at the unit-testing code level, leaving a lot of code non-testable. It also makes integrating with other systems more painful than it should be. And it doesn't leverage hypertext in any way, because state is transferred across postbacks through either the session or the viewstate.
In this model, the resource is the page, and does many things. It's completely unrestful.
The MVC model
A lot of noise is being made about the new asp.net MVC framework. MVC as a pattern solves some of the issues introduced by webforms. Your Url is bound to a controller that receives the request, act upon it and send you to a view based on the result of the operation. This solves the unit-testing issue. To a certain extent, it also solves partially the integration issue, as your controller can act upon the http operations (GET PUT POST DELETE etc...).
That said, your Url is bound to a controller's action, so you would end up most of the time with a url looking like http://example.org/Customer/GetCustomer. You're mapping one web action to an operation. While you can override that, it's not the default. Another issue that makes it unrestful is the lack of leverage of hypertext, as links are not used for anything meaningful unless you implement that yourself.
In this model, the resource is the controller, and does quite a few things. It's up to you to define the semantics. It's quite unrestful.
The WCF Rest model
WCF in 3.5 has some support for something quite similar to the model provided by MVC. Your WCF service can be mapped to a specific Url and encoding (xml and json), and it will support a Get and a notion that team came up, an invoke. The rationale being that there was not that much of a different meaning between POST/PUT to justify mapping them differently, and that they all end up invoking a service.
This is a service-centric view that maps very poorly with the web. You're tying your Url to a service operation, and limit your representations to the two kinds provided by WCF. Its great for unit testing, not so much for the web.
I'll also have to question any team having spent that many years providing an abstracted toolkit that lets you not think about the plumbing (although this is a very big white lie) trying to implement a REST architecture which is, by definition, about the plumbing, leveraging Http verbs and hypertext.
In this model, the resource is the service, and does something. It's quite unrestful as well.
The Ado.net Data Services model
Formerly called Astoria, ado.net data services is the most restful of the APIs Microsoft is working on.
With Astoria, you map a Url to an entity (ado.net entities), and you interact with those entities based on AtomPub, which is quite restful. That said, it is about exposing your existing entities model on the web, and support for POX / POJson has been dropped from what I understand.
It does leverage hypertext (because AtomPub does), and it does have some content type negotiation. The big issue here is that it doesn't integrate with any of the previous models we've seen, and is yet another API that wants to have the Urls in your web application to itself. It supports data, and data only, so you won't be able to leverage an asp.net MVC page to serve a resource as text/html, and still support application/json for clients that want this format.
In this model, the resource is the entity, and you can do restful things with it. But it only deals with one aspect of developing rest applications, and has poor integration with the other components Microsoft is developing.
The Rasta model
Rasta takes a radically different approach. Every Url is mapped to a resource. In other words, http://example.org/Customer is mapped to a resource of type CustomerEntity. Each resource type can have many resource handlers that are responsible for acting upon a resource in a certain way. This could mean retrieving a resource, updating it, etc.
When you access a Url to get to a resource (called dereferencing), the first step Rasta is going to take is to try and locate which handler can be used to access the resource, based on the request you made. For example, http://example.org/Customers/{name} is a Url that would associate a meaning of name with a value to the handler. From that name, the handler would return an instance of the resource (an instance of CustomerEntity). In other words, a handler is responsible for dereferencing a Uri based on a request to get to a resource, and to act upon it if required.
And that's it. The handler is not involved at any point in how the request is processed or how the response is sent to the client. This is the responsibility of the codecs.
A codec is a component that, to simplify, convert a Content-Type sent on the wire to an object and back. In essence, if your handler returns an instance of CustomerEntity, the codec will be able to convert it into an xml stream representation, or whatever wire format the codec supports. Out of the box, the current Rasta svn repository has support for webforms (for html rendering), json and xml, and I have some working code supporting AtomPub, atom, rss and even support for some WebDav, although all this is mostly prototype quality.
In this model, the resource is the resource, and its representations are handled by codecs that are loosely coupled from the resource itself. You could see it as an application of the semantic web, but based on types and objects. In other words, it works and is good enough.
Conclusion
Rasta's architecture brings quite a few benefits:
- Loose coupling between the representation of a resource and the code that does useful stuff with it.
- Automatic support for content-type negotiation, letting the client decide what is the best format to receive a resource in.
- Resources don't change, but implementation of the handlers can
- Adding new content-types is independent from the rest of your code
- Adding things like AtomPub becomes very easy
- You have only one way to do both your html representation and the computer-friendly ones.
- Oh, and it's still compatible with webforms so you can retrofit existing work in the same site
- And as a nice to have, it runs on standard .net 2.0.
There are many other parts to Rasta, but those are the basis of what it is, why it was built, and why I'm so thrilled about it.