Huddle » Blog » Huddle news » We love OpenRasta

We love OpenRasta

Posted on 06 Apr, 2009 by in Huddle news | 3 comments

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.

Enter OpenRasta

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.


  1. Leon Jollans

    August 12, 2009 at 12:58 am

    Before I start, let me say that I don’t know OpenRasta and I found your article as I was in the process of researching it. So I’m not commenting on OpenRasta at all, rather defending WCF.

    As such I have a couple of comments. As I’m sure you know, WCF is far more than just a SOAP framework. Sure you can do the full blown SOAP 1.2/WS-Security/WS-Policy thing, and that is necessarily complex, but you’re talking about a different business scenario to the ones that thin RESTful style services suit – and indeed are appropriate for.

    WCF supports virtually any transport and virtually any message protocol. Those that don’t already exist can be developed bespokely with a degree of effort not far removed from the complexity of the protocol in question.

    You can also, out of interest, use something like the WCF REST starter kit off Codeplex ( which uses nothing more than the built-in WCF plumbing to do pretty much precisely this, and leaves you reasonably able to concentrate on API.

    admittedly the WCF setup from scratch is not for the faint-hearted, but look what you get… by changing a bit of config you can load balance your service, or switch to a binary transport.. or attach your own PKI encryption with client and server certs. And at no point have you changed your domain code to achieve this. Now, I recognise that this is not a requirement for all solutions, and I recognise that there are significant scenarios where this sort of flexibility will never be a requirement, but it is important to be clear about what you do and don’t gain by using WCF or not, and it’s important to recognise that it’s a profound business decision.

    In a way I see it as similar to using something like NHibernate. By decoupling your resource management code from your domain logic, you can remain resilient to changes that would otherwise either require significant effort to absorb or even be insurmountable without a rewrite, and these abstractions are often critical to an appropriate solution architecture quite regardless of the development methodology or tools employed to deliver the service implementation itself.

    Additionally, the use of WCF does not prevent you writing fluent DSL-like builders for your data objects. I am a huge fan of this sort of fluent API, and the little extra effort required in writing wrapper builder classes to support such an API is perhaps always worth its weight in gold for subsequent readability and reuse.

    That all said, for all I’ve seen, heard or read so far, OpenRasta certainly sounds interesting, but I’m not really in any position to comment on it yet, I’m merely sticking up for WCF – which really doesn’t need to be as complicated as it ostensibly expects. I admit it’s not perfect, and the learning curve is pretty steep, but it’s really very good, and it certainly doesn’t prevent you building lightweight solutions. The payoff, I would say, is that it gives you the ability to add serious, professional, enterprise level features to your lightweight services with arguably less effort than any comparable alternative.

  2. Bob Gregory

    August 12, 2009 at 12:35 pm

    That’s an extraordinarily well argued comment, I’ll try to do it justice in my response.

    I’m a fan of WCF for very specific cases. I think it’s a beautifully over-engineered framework, and you’re correct that it’s the best choice for serious, enterprise-level interop work.

    If I were trying to get a Java system to talk to a .Net system, and I wanted those kind of features, WCF would be the only logical choice.

    That’s not the requirement for our APIs which (once they’re actually in place) are very much designed for ease of consumption.

    You’re also correct that you *can* build lightweight systems out of the box with WCF, but you have little control over the functionality of those systems unless you’re willing to get your hands dirty and delve into some heavy fundamentals.

    For example, we use SSL termination on our load balancers so that our traffic to the outside world is encrypted, but we avoid the SSL overhead on our backend servers.

    Implementing SSL termination in WCF is an extraordinarily confusing process, and it took me the better part of a week to get it up and working.

    The core abstractions of WCF are extremely flexible, and you can extend it at pretty much every point, but there are so *many* points that it can be hard to find the right one.

    This is a necessary consequence of the vast scope of WCF. By contract, OpenRasta, does one job extremely well – mapping an incoming HTTP request to a handler, and returning some domain object with a client-negotiated serializer.

    Extending OpenRasta is a snap. URI decorators and Pipeline contributors are easy to write, and the framework is tiny enough that you can hold a conceptual model of the whole request lifecycle in your head.

    It’s the simplicity and single-mindedness of OR that makes it the best candidate, IMHO, for writing RESTful services in .Net.

  3. Leon Jollans

    September 18, 2014 at 5:12 pm

    Wow, five years ago! I just came across this searching for things I’d written before. Possibly egosurfing a little too, not for me to say.

    In that five years I have used OpenRasta for a number of projects, and yeah I have to say it’s remarkably good. Certainly better than ASP.NET MVC in my humble opinion, and I will sing its praises to anyone who wants to listen. In that five years also, I have worked on a number of fairly major WCF projects too, and MS have raised the bar somewhat with regards to the lighter weight jobs and JSON for example too. But that all said, their places are measurably different to my mind. And WCF still isn’t that RESTful, REST being more than JSON and HTTP Accept. I am still a huge fan of WCF on the larger scale server side, n-tier multi tenant systems and so forth, but yeah given freedom to do so I would choose OR for the web tier in a heartbeat. Certainly over ASP.NET MVC and all the funky Entity Framework wizards that seem to be awfully popular of late.

    Just thoughts anyway. All the best :)

Join the discussion