Moving from WebAPI to ServiceStack

Having used WebAPI in conjunction with a hybrid WebAPI and ASP.NET MVC app quite recently, it does a good job, but once you start to get deeper in a more complex application some weaknesses start to show. A trivial example is mapping exceptions to HttpStatus codes, this is something you get easily with ServiceStack.

The WebAPI controllers looked like this, with a route prefix at the top, and then the specific part with

    [RoutePrefix("/api/product")]
    public class ProductController : ApiController
    {
        [GET("{id}")]
        [AcceptVerbs("GET")]
        public Product Get(ProductId id)
        { /* ... */ }
        
        [POST("create")]
        [AcceptVerbs("POST")]
        public void Post(CreateProductCommand cmd)
        { /* ... */ }
    }
	
    // New style as route decorating an F# record
    [<TypeScript>]
    [<Route("/product/create", "POST")>]
    type CreateProductCommand =
    { 
        ProductId: ProductId
        Name: string
    }

Yes F#, checkout out my post on initial learnings with F#. There’s something interesting about our route decorations on that record type, I’ll try to get around to writing about it. But for context this time round it’s

Issues with WebAPI

Our primary issue with WebAPI was that its route matching was limited.

As a result, it frequently did not match routes in an expected way. This often resulted in a great deal of time lost to fiddling about and trying to come up with a pattern that would satisfy what Web API wanted, often at the expense of our public API design. Also, we wanted to take advantage of routing features that already exist in ServiceStack, but are still only planned in the future for WebAPI.

Finally, as our product’s hosting needs grow, we may like to take advantage of cheaper Amazon machine images and run our services on Linux; ServiceStack is a first-class Mono citizen.

Conclusion

We’re quite happy so far having run it for ages.

[Update]
Months later in production still very happy.

Advertisements