They have very similar use-cases, as the lead maintainer for the ServiceStack project I have a good insight into ServiceStack's advantages and the many natural benefits of its message-based design.
ServiceStack has been around since 2008 as an OSS-run project from its inception with a single goal of promoting the correct design and implementation of friction-free remote services.
Simple and Elegant Design
In its pursuit for ultimate simplicity, it's built around a simple and elegant core - with most of its features naturally binding to your models, not your controllers - which is what MVC, WebApi does (as well as every other Web Service Framework Microsoft has produced).
Adopting a message-based design offers a superior approach for remote services, in that they promote more extensible and less brittle services, simplifies access and calling patterns, and contain many other natural benefits you get for free.
As a core mission, we fight complexity at every stage, aiming to keep an invisible and non-intrusive API and avoid introducing any new concepts or artificial constructs that aren't already familiar to .NET or web service developers today.
As an example your IService<T> service implementation is just a standard C# class with auto-wired dependencies. Thin and lightweight wrappers are used to provide a consistent and unified API around the core run-time IHttpRequest and IHttpResponse types. They also allow access to underlying ASP.NET or HttpListener's Request and Response classes so you're never restricted when using ServiceStack.
Contrasted with WCF and WebApi
Here's a brief overview of the contrasting API styles that ServiceStack and WCF promote. WebApi is different to WCF in that it encourages REST-ful API design. As for examples between the 2, this is the only known example I have with the same service written in both ServiceStack and WebApi.
Best Practices remote services
ServiceStack has a primary focus on simplicity, performance and in promoting web/remote service best-practices centered around embracing Martin Fowlers remote-service design patterns in as idiomatic C# as possible:
The Facade Pattern - Which suggests the usage of batchful, coarse-grained interfaces when ever you communicate across process boundaries.
The DTO pattern (MSDN) - Dictating the use of special-purpose POCOs to generate the wire format of your web services responses.
The Gateway Pattern (MSDN) to encapsulate your client and server communications between the Client Gateway / DTO models and Service Interface tiers.
These patterns ensure a clean separation of concerns and a friction-free iterative dev experience.
Empowering your services
A ServiceStack web service at its core is centered around a dependency-free and auto-wired pure C# IService<T> interface that gives you complete freedom to define your web service contract with your own Request and Response DTOs using clean POCOs - rendering ServiceStack's API practically invisible and non-invasive, i.e. it's trivial to extract your C# services logic and run it outside of a ServiceStack host.
This gist is a good example of what you get with just 1 C# .cs class in ServiceStack:
- Metadata pages for all registered formats
- With links to WSDLs, XSDs and C# client examples
- Human friendly HTML report view
- A single self-contained html page snapshot (i.e. no external refs). Includes embedded JSON web service response - allows programmatic access to data snapshots.
- Built-in Mini Profiler (port of the excellent MVC Mini Profiler)
- JSON/JSONP, XML, JSV, CSV and SOAP end-points
The RestServiceBase and ServiceBase classes are intended to host your custom C# logic for maximum potential re-use as possible, e.g. Its DTO-first design trivially allows for deferred and proxied execution where your same C# Service can also be hosted and executed in an MQ Host which is what happens when you register an IMessageService like the RedisMQ host and call your service via the /asynconeway endpoint (i.e. client.SendOneWay() in C# Clients)
You can also easily delegate and create composite services using the base.ResolveService<T>() method which returns an auto-wired instance of the selected service as seen in the Nortwind CustomerDetails Service example:
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
Return plain C# objects
For the most part ServiceStack will serialize most C# objects as expected - here's a list of possible return types (from this answer):
- Any DTO object -> serialized to Response ContentType
- HttpResult, HttpError, CompressedResult (IHttpResult) for Customized HTTP response
The following types are not converted and get written directly to the Response Stream:
- String
- Stream
- IStreamWriter
- byte[] - with the application/octet-stream Content Type.
An example of the Custom HTTP headers support can be seen by this CORS example where you can configure HTTP Headers globally or on a per-service basis.
HTML Support
There are multiple options for returning HTML in ServiceStack that is explained in detail here.
Includes fastest text and binary serializers for .NET
Resilient and fast serializers are of primary importance in an API to ensure fast response times and a versionable API which doesn't break existing clients which is why ServiceStack includes the fastest text serializers for .NET with a NuGet option to enable @marcgravell's Protocol Buffers (.NET's fastest binary serializer).
ServiceStack's text serializers are very resilient and can withstand extreme versioning without error.
Friction-free dev experience End-to-End
ServiceStack's opinionated nature allows for a fast, typed, terse web service API end-to-end with built-in support for Sync/Async C#/.NET and Async Silverlight clients without any code-gen:
Sync C# Example
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
Async C# Example
client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });
As it just returns pure JSON it's also trivially consumed with other HTTP Clients, e.g. JS client example using jQuery:
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Highly testable
All C#/.NET ServiceClients share the same interfaces which make them highly testable and swappable to the point where you can have the same unit test also serve as an XML, JSON, JSV, SOAP Integration Test.
Rich Validation and Error Handling built-in
In its mission to provide a friciton-free and clean dev experience, ServiceStack also includes typed validation and error handling built-in where throwing an C# Exception or using its built-in Fluent validation provides clients structured, typed errors easily accessible on web service clients, e.g:
try {
var client = new JsonServiceClient(BaseUri);
var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
/*
webEx.StatusCode = 400
webEx.ErrorCode = ArgumentNullException
webEx.Message = Value cannot be null. Parameter name: Name
webEx.StackTrace = (your Server Exception StackTrace - if DebugMode is enabled)
webEx.ResponseDto = (your populated Response DTO)
webEx.ResponseStatus = (your populated Response Status DTO)
webEx.GetFieldErrors() = (individual errors for each field if any)
*/
}
To make it trivial to consume errors in JavaScript, you can use the lightweight ss-validation.js JavaScript library to trivially bind your response errors to your HTML form fields with a single line of code. The SocialBootstrapApi example project provides a good demo of this.
Rich Integration with ASP.NET and MVC
The ServiceStack MVC PowerPack re-writes and fixes a lot of the ails of ASP.NET and MVC with replacements for its crippling Session and Caching XML-encumbered ASP.NET providers with its own clean and dependency-free implementation of ICacheClient and ISession APIs.
ServiceStack also includes a newer and cleaner authentication and autorization provider model with a number of different AuthProviders in-built:
- Credentials - For authenticating with username/password credentials by posting to the /auth/credentials service
- Basic Auth - Allowing users to authenticate with Basic Authentication
- Twitter OAuth - Allow users to Register and Authenticate with Twitter
- Facebook OAuth - Allow users to Register and Authenticate with Facebook
The Authentication module is entirely optional and is built-on the clean ICacheClient / ISession APIs and OrmLite which allows your Sessions to be stored in Memory, Redis or Memcached and your UserAuth info persisted in OrmLite's supported RDBMS's of SQLServer, MySql, PostgreSQL, Sqlite as well as Redis data-store or InMemory (useful for dev/testing).
Great Documentation
ServiceStack is very well documented where most of the information about the framework is hosted on the GitHub wiki. Documentation for other parts of the framework (e.g. Serializers, Redis, OrmLite) can be found on servicestack.net/docs/
The ServiceStack.Examples Project provides the source code for all of ServiceStack's live demos and Starter Templates whilst the SocialBoostsrapApi project provides a great starting point of developing a Backbone.js Single Page App with ServiceStack and MVC based on Twitters Bootstrap template.
In addition to the above a treasure trove of information is contained within the Google Group which has expanded quite considerably in recent years.
Runs Everywhere
ServiceStack is a .NET 3.5 framework that runs on ASP.NET and HttpListener hosts and can be hosted on either .NET or Mono (trivia: www.servicestack.net is powered by CentOS/Mono). This allows your ServiceStack web services to be hosted on either:
Windows with .NET 3.5 & 4.0
- IIS 5/6/7 (uses IHttpHandler)
- VS.NET WebDevServer
- Console App or Windows GUI
- Windows Service
Linux/OSX with Mono
- Apache + mod_mono
- Nginx + MonoFastCGI
- XSP
- Console App
Developed with the Open Source development model
ServiceStack is a strong believer of the Open Source development model where it is actively developed in the open and has always been hosted under a liberal OSS licence (New BSD) since its inception. As of today it has received contributions from more than 47 developers and it currently stands at the 3rd most watched C# project on GitHub.
Disadvantages
I believe the biggest disadvantage is the same for most other OSS .NET projects where it wasn't developed (or even listed as an available option) by Microsoft. This means it's rarely ever the first choice when evaluating a framework. Most adopters will only evaluate ServiceStack as a last resort, where they're either frustrated with the imposed friction and brittleness of WCF or the performance of the preferred Microsoft Stack.
Feedback and Community Resources
ServiceStack has been very well received with positive feedback provided by most people who have evaluated it as visible by the positive sentiment in the mailing group. As of this year the @ServiceStack twitter account has been tracking mentions and feedback in its favorites.
The Community Resources wiki page is a good place to find out more about ServiceStack in the wild with links to Blog Posts, Pod Casts, Presentations, Gists and more.
