As someone who has been knee deep in WCF for years and now diving into WebAPI I still don't understand the real differences between ServiceStack and WebAPI. It seems like this answer was written well before WebAPI was released or fully baked. Now that it's out is there anything new you can tell us?

So far, I've been able to achieve everything I need using just WebAPI and Attribute Routing[1]. Is there something fundamentally different you can demonstrate or describe for us? I did some research on ServiceStack and the only thing that stuck was that you also had your own serialization libraries too. (Although I still prefer JSON.Net) I guess what I'm looking for are the Can Dos and the Can't Dos too. Not just 'we like this approach instead'.

[1] https://github.com/mccalltd/AttributeRouting

Edit - Reworded.

Check out the: Advantages of message-based web services https://github.com/ServiceStack/ServiceStack/wiki/Advantages...

Which explains the natural benefits of the design ServiceStack promotes (no other MS fx promotes this). We strongly believe that message-based services promote the best practices for remote service development, something we've benefitted from for years.

ServiceStack is different in that it can support the same service running on SOAP, MQ endpoints (in addition to JSON, XML, JSV, CSV out-of-the-box) it even can be re-used as the controller for HTML web pages, see: http://razor.servicestack.net

Thanks! I'll do some deeper investigation today for sure.