I wrote last time about some of the things we want to do in order to make our application open for extension and integration. I get asked quite regularly what technologies we’re using at Huddle, so I thought I might spend some time talking about the stack we’re going to build all this on.
We’re a .Net shop from top-to-bottom. Until recently, we’ve been developing our REST API with Windows Communication Framework, but we’re starting to reach some serious limits with the solution.
If you don’t already know, WCF is Microsoft’s ambitious solution for building service-oriented systems. It’s actually a well designed, extremely flexible model. WCF is hampered, however, by Microsoft’s focus on SOAP as the One Protocol to Rule Them All. If you want to create a seriously enterprisey service, where messages are secured with WS-Security using X509 certs; where messages have guaranteed delivery over MSMQ and WS-Reliability; and you want to provide transaction contexts with WS-Transaction and WS-Coordination, it’s great. You can run hog-wild with SAML tokens, and federated identities, and channel factory selection strategy factories until you’re so bloated with over-engineering that you have to go for a nap to recover.
It sucks for building thin REST services, though.
We’re going to start working on the second version of our API in the next few weeks. V2 will be a bit more RESTful than V1, and while v1 had frequent breaking changes, V2 should be a solid platform for people to build upon. The new version will be built on top of a neat little framework called OpenRasta, developed by the beautiful and talented Seb Lambla.
OpenRasta is nominally an MVC framework, but it actually solves a slightly different problem in a very elegant way. What Rasta does extremely well is to map an incoming request to a handler method, and provide serialization/deserialization for multiple content types at a single URI. Seb’s building an MVC framework *on top* of that core, but it’s the core that we’re adopting.
There’s a neat fluent interface for configuring it, that looks something like this:
[code lang="csharp" light="true"]
// Define some basic codecs to handle all our DTOs.
// visiting /people/123 returns you the person with the id 123.
// In addition to the formats above, we want to provide VCard and HCard data.
// A list of people can be viewed in any of the formats above at the uri /people
ResourceSpace.HasResourcesOfType< PagedList<PersonDto> >()
Why OpenRasta is winful
What’s immediately noticeable about Rasta’s config is that you are forced to represent your domain layer as resources. Instead of just mapping a URI to a method, we’re mapping it to an *entity* within the domain space. That entity is resolved by a Handler and is transcoded by a Codec.
Transcoded is the operative term here. In most MVC frameworks, there is a flexible way of mapping a request to a view, so that you can send data back as HTML or JSON or LOLCode; the really gorgeous thing about OpenRasta’s model is that this mapping is symmetrical – the ability to read multiple content types is just as important as the ability to return those content types.
We’ve found it hard at Huddle to make the conceptual jump from writing RPC calls – á la JSON-RPC or SOAP – to writing a RESTful set of services. The highly opinionated nature of OpenRasta makes it easier for us to stay on a resource-oriented track. The symmetrical codec model also makes it much simpler for us to plug in multiple request/response formats.
It’s a technical risk adopting an open-source project that has such a small following, especially before it even hits beta 2; but the core of OpenRasta is the codec and pipeline model, which have been mostly stable for the last six months. We’ve still got a way to go, particularly around exception management and authentication, but Seb has some ideas on that already, and we’ve run a spike to hack those features in, so I’m confident that the second beta of OpenRasta will meet all our needs.
We’re very happy to be working with Seb on this, and we’ll be pushing OpenRasta as the best option for RESTful services on the .Net platform. Hopefully the project will start to gather some momentum in the community, because where it gets things right, it gets them absolutely spot on.