Late Happy New Year to everyone!
For the first of 2012 let’s start with a short series of post about my adventures in finding a suitable web framework that makes likeable building REST services.
Corralling the Problem
Very rarely I write about concrete pieces of work I perform for my customers. This time I will break the rule, since this instance is about a proof of concept and no details are going to be given away.
Hopefully, someone that faces the same problem I faced when choosing, can find my journey interesting.
The proof of concept that scopes my findings is about creating simple URL-accessible read-only services. The information returned can be localized and be returned in various formats (XML and JSON), chosen by the consumer. Of the services to be built, the most “complex” is returning some sort of catalog information, having two endpoints: one that returns a snapshot of all of them and another endpoint that returns an extended version of a single one.
Non-Functional
As the reader can see, the functional requirements aforementioned are really simple. The non-functional requirements will, as well, be concrete.
For one, services need to be easy to develop. That rules out any framework that require extensive configuration and/or a great deal of ceremony (yeah, WCF I am looking at you!).
They also need to be HTTP-friendly. HTTP is a simple protocol but often misunderstood and underestimated. It covers all my requirements and a great deal more. For example, content negotiation is possible by expressing a rich set of formats accepted by the client in the headers, and extra formats can be defined to cover scenarios such as versioning. Likewise, localization is achieved with the same technique, including a weighted list of languages the client request the information in. Standard return codes provide a standard vocabulary of possible outcome and caching information can be specified.
Unfortunately, as rich as HTTP is, there are a wealth of bad clients to the protocol and shortcuts to be taken. Of those, we contemplate an easy way to override both the language and format of the response by the means of providing query-string arguments.
Nice-to-have extras that won’t probably be needed in the firsts versions are:
performance: it should lightweight enough to not become a problem when multiple clients perform requests. I want my code to be the scalability problem if they ever exists
extensibility: being able to easily get in the middle of the request pipeline at several stages in order to clean up the implementation of the service itself
coolness: it should be pleasant to work with and have a strong community that can provide knowledge when newer features that need advanced usages come. OSS is a plus, but not required. Oddly enough all the frameworks analyzed give access to their source code.
The Contenders
My time is limited for the task and there are lots of such frameworks that can be used for my problem. So I framed the products to evaluate to:
- Nancy
- OpenRasta
- ServiceStack
- WebApi