Menu
No, it's not true that ASP.NET Web API has replaced WCF. WCF was generally developed to develop SOAP-based services. ASP.NET Web API is a new way to develop non-SOAP-based services such as XML, JSON, etc.
ServiceStack is a configuration free, code-first, light-weight framework built on top of ASP.NET for building services and web applications. As the name suggests, it is a stack of services. It provides with just everything that one needs for building end-to-end web services.
There are many differences between MVC and Web API, including: We can use the MVC for developing the Web application that replies as both data and views but the Web API is used for generating the HTTP services that replies only as data.
Before I illustrate how an ASP.NET MVC controller can be used as an API or a service, let's recap a few things: Web API controller implements actions that handle GET, POST, PUT and DELETE verbs. Web API framework automatically maps the incoming request to an action based on the incoming requests' HTTP verb.
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.
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.
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.
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.
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:
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 });
For the most part ServiceStack will serialize most C# objects as expected - here's a list of possible return types (from this answer):
The following types are not converted and get written directly to the Response Stream:
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.
There are multiple options for returning HTML in ServiceStack that is explained in detail here.
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.
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:
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
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);
});
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.
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.
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:
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).
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.
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:
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.
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.
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.
There is a new main difference that needs to be accounted for - ServiceStack is no longer free to use as of v4. Since there is a pretty definitive answer on the SS pro's I wanted to throw a couple out for Web API
Pro's :
Con's :
Ancillary Benefits
(Please feel free to leave comments below adding to why Web API has benefits or has pros / cons I can add)
I can't really say much about ServiceStack, but Web API has a lot of great features and is currently at version 2.
Some of the things you can do with Web API:
async and await.As a customer of ServiceStack here is the pro for ServiceStack most important for me.
https://github.com/ServiceStack/Issues/issues/606
So. Bug found, bug identified, bug fixed. Same day. Extraordinary support!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With