Evaluating Data Services options – WCF vs WebAPI vs ServiceStack

SOA has been quite popular in recent years and is something to strive for. However, there are so many technology options for creating and hosting services. In addition, there exists many SOA definitions and ways of implementing SOA standards. We have bumped our heads and came close many times to slitting our wrists by using WCF. Below are my opinions on WCF and 2 other of the main technologies used to build services.


Requires the creation of DataContracts and OperationContracts. It follows a RPC style architecture.This has been for many years the defacto standard of implementing services using the Microsoft Stack.


  • Huge support in .NET community as it is included by default in Visual Studio Templates.
  • Big support from Microsoft.
  • Lots of resources available.
  • Add Service Reference is very easy to use.
  • Many features


  • Inflexible and brittle
  • Difficult configuration and setup
  • Huge learning curve
  • Difficult to debug and host
  • Difficult to add REST and JSON support
  • Very limited content negotation support
  • Lots of configuration required
  • Cross domain calls from JavaScript is very difficult and almost impossible across different browser versions.
  • Add Service Reference provides many problems with re-use of code.
  • As a developer, I hate working with this technology.


Microsoft’s answer to support REST. Use controllers to setup REST endpoints. Used within a Web project only.


  • Built in Visual Studio templates.
  • Similar programming style to MVC controllers.
  • Easy to use and reasonably easy learning curve.
  • Lots of resources available.
  • Supports JSON, XML and FormData content types out of the box.


  • Very new technology.
  • Complicated Route configuration.
  • Dependency Injection is difficult.
  • Only REST is supported – Need to maintain separated code bases to support REST and SOAP.
  • No code re-use between MVC types (controllers) and WebAPI types.
  • Limited hosting options.
  • Difficult to add custom content negotiation types.


ServiceStack is a bit of a different mind set as it is built using HTTP handlers. This is an open source project (stable since 2008) that was built using SOA and Integration best practices. It is built around Message Contracts (rather than OperationContracts) to which many big companies adhere to – such as Amazon and Google.

Benefits of message contracts: https://github.com/ServiceStack/ServiceStack/wiki/Advantages-of-message-based-web-services

For more info: https://github.com/ServiceStack/ServiceStack/wiki



  • Metadata page that exposes all services and usages.
  • Supports content negotiation
  • Built-in data and content negotiation types: JSON, XML, CSV, JSV, SOAP, ProtoBuf, HTML, Text, byte[], Stream, IStreamWriter
  • Easily add custom content negotiation types.
  • Multiple hosting options – Website, Console App, Windows Service
  • One of the fastest serializers in .NET.
  • One of the fastest ORMs in .NET.
  • Plug-in model that allows the addition of features on global or service level (pipe and filter model).
  • Support for most clients and formats.
  • OSS from 2008 – free and many contributions
  • Strong security model – built in support for OpenId 2.0 providers.


  • OSS – most corporate companies prefer paid support structures.
  • Lack of built-in Visual Studio templates – need to use NuGet 

My conclusion is that ServiceStack looks very promising and as a development team we would love to through away WCF because of all the issues we have experienced over the years. We are currently building some prototypes and so far it looks good.



Tags: , , , , , , , , ,

5 Responses to “Evaluating Data Services options – WCF vs WebAPI vs ServiceStack”

  1. Damian Says:

    If you need SOAP, then SS is the only one of the OSS frameworks that supports it. If you also need HttpServices (*cough* “ReST”), then you should also consider NancyFX.

    You should also consider OWIN support, as this will open a multitude of hosting options as well as composability, i.e. using multiple frameworks in you app that work for your needs. NancyFX and WebAPI fully support OWIN. WCF does not. SS not on master.

    Do you need async (TPL) support (which is becoming standard these days)? WebAPI supports async now. Nancys’ is in beta. SS doesn’t.

    No mention of testing / testablity? ServiceStack, Nancy and WebAPI provide different options but are different ‘flavours’. Evaluate those too. http://blog.jonathanchannon.com/2012/11/29/asp-net-web-api-testing/

  2. Demis Bellot (@demisbellot) Says:

    Damian, ServiceStack will support OWIN as soon as OWIN shows some tangible benefits for doing so. ServiceStack already has ASP.NET and HttpListener self hosting options, as soon as there’s a new better production hosting option available we’ll add support for it.

    While async provides advantages on the client by not blocking the main UI thread (and all our clients provide async APIs), we believe its absolutely wrong to encourage for services for multi-threaded platforms such as .NET, it only adds complexity when we should be taking it away. Caching is a infinitely times better than async for performance/scaling that doesn’t require rewriting all your server logic and embracing the inherent complexity of async, it’s where we believe we should be focusing our efforts on. Unfortunately caching options are weak in .NET and has been overshadowed by the noise of those who keep re-iterating “its async so must be good” cargo cult mentality, when none of them have shown any benefits, esp. over caching. Many dynamic languages recognize this and have excellent support for rich caching patterns. YouTube is built on 1M lines of blocking Python – async isn’t the reason why .NET isn’t a popular amongst startups and large Internet sites and APIs – complexity is.

    Async makes sense in node.js because it’s single-threaded and all their I/O Apis are non-blocking – i.e. it traded the complexity for multi-threading for async, whilst .NET was the opposite, all their API’s started off as blocking, so it embraced the complexity of multi-threaded programming so it can do blocking I/O and retain sequential flow of execution like the rest of your logic. ASP.NET is a multi-threaded server and embracing async in addition to multi-threading is the worst of both worlds.

    You can always call async code inside your ServiceStack services and block at the end before returning a result, but as async support is being marketed as a missing feature rather than something that should be discouraged in server programming – it looks like something we’ll be reluctantly forced to support.

  3. Dave Says:

    What did you end up going with?

  4. Raj Says:

    I have a necessity to use async/await in my industry as we send out requests simultaneously, wait for a response within a certain time and proceed to next step. I’m very new to ServiceStack and so far I’m loving it. I’m trying to implement a replicating service that I have in WebAPI that uses PostAsync and ContinueWith. I see that there are AsyncClients, but I don’t see them supporting ContinueWith. In MVC 4 / Web API I had issues with Async / Await, which got solved by ContinueWith like httpClient.PotAsync(endpoint, requestMessage.Content).ContinueWith(…

    (a) Would Async/Await work better than MVC 4 / Web API implementation?
    (b) Also can I use the [AsyncTimeout()] attribute?

    As I see that the Async support is still in ‘Doing” phase here https://trello.com/b/06t4eotn/servicestack-features-bugs, could you please advice if there is a better pattern to use.

    Thanks in advance


  5. Trevor de Koekkoek Says:

    I like ServiceStack and am seriously considering it for future projects. However I do take issue with a few of your points regarding WebAPI:

    Complicated Route configuration. – I don’t know what is complicated. It works pretty much out of the box and uses the same configuration as MVC.

    Dependency Injection is difficult – Again I don’t know what is difficult here. It’s .NET. Hook up DI as with any project.

    No code re-use between MVC types (controllers) and WebAPI types. – The base controllers are different classes, true, but you can share any amount of code between these layers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: