Since my research in to REST I couldn’t help but feel there was something missing in the .NET community for developing RESTful services. The REST starter kit from Microsoft really didn’t cut it for me, it still left a lot to be wanted, such as security, caching, and other bits. So naturally, I dared myself to write a REST service framework.
I gathered all my thoughts and concerns around REST , and realised that if I was ever to going ensure REST services were to become a common practice in a work place that has never done/seen REST before, then either strong governance would have to be put in to place, which is a cost, or, create a framework in such a constrained way that it didn’t allow people to produce RESTful services outside of the rules that govern RESTful architecture. I also set out to make REST as easy as producing and consuming a web service in .NET.
The most natural thing to do was take all the abstractions of REST, what was going to be completely common across one REST service to the next, and keep this in meta-data. To create this meta-data, I developed a thick client that allows me to visually design the resources, set the content types of representations, and control caching etc. This service studio tool would also validate the meta-data to make sure things like creating a resource that allows GET, has appropriate representation content types defined.
Here’s what it looks like so far:
The meta-data of the service produced from this studio is then loaded in to the service framework that runs in WCF 3.5, and the only thing left up to the developer is to map the data layer to the resources for the appropriate HTTP methods.
My feelings so far is that REST puts you immediately at the starting line of web services, and I feel a little uncomfortable not having the full support of WS-* profiles, like what “Big Web Services” via SOAP give you, but, did I really ever use them? What really excites me, is how easy it is to throw data out in so many different formats. One of my examples was exposing a repository of configuration settings via an Atom feed, and very quickly, I could subscribe to the data repository and notify when configuration items changed that were perhaps important to me in a business environment.
If you’re interested in any of this described above, drop me a line at email@example.com.