Share or discuss this blog post with me on Twitter

This post is simply a list of gotchas for anyone using the ServiceStack services/API framework in conjunction with RestAngular client-side JavaScript framework.


For me, ServiceStack is the best API framework available to anyone working on the .NET server-side stack. Sure Web API is getting the most traction as a Microsoft product, but its still playing catchup in my eyes. ServiceStack was espousing the virtues of a clean, lightweight service framework based on Data Transfer Objects (DTOs) way before Web API and may even have been the inspiration behind Web API. Not that being first gives it any more credence, but rather the original thoughts and principles were there and have been built upon and extended throughout the versions of ServiceStack. That solid and simple foundation gives me so much confidence in the product.


It is said that there is a JavaScript library for every function imaginable nowadays, and it does seem to be true. In my opinion, there is value in the argument that this isn’t necessarily a good thing. (if the functionality required is simple, straightforward and small enough then it is more beneficial in the long run to roll your own rather than potentially having to debug through open source code written by someone else.) Which is why I was surprised to find a dearth of choice in solid client-side REST consumer libraries out there. Sure, you could write you own, but it does seem like an ideal candidate for a boilerplate library (common requirement, infrastructure code, large and complex enough not to want to write your own from scratch). I settled on RestAngular because it seems to be the best of the bunch. (Still, I found there to be a distinct lack of support and documentation out there on RestAngular.) If anyone out there can correct me on this, I’m happy to listen.

So, if you are using both ServiceStack and RestAngular, bear in mind the following nuances I have come across so far.


Cross Origin Resource Sharing (CORS) is essentially an HTTP specification/mechanism to control sharing and distribution of resources across domain boundaries. Therefore, if you are hosting your ServiceStack API service on a separate server from your web application, then you have to configure it to allow CORS. To do this, you need to configure ServiceStack explicitly to allow cross domain requests. Please see this StackOverflow answer for the ultimate answer on how to achieve this from the man himself, Demis Bellot. As a security specification, it makes sense that you have to explicitly enable cross domain resource sharing rather than explicitly disabling it. More on CORS can be found here. While this is not specific to the ServiceStack and RestAngular combination, it is definitely worth mentioning here.

Content Type

Ensure you set the content-type for your headers in RestAngular, otherwise you will get “empty” request DTOs (all null values).

If you want to do this globally you can configure your RestangularProvider on setup as follows:

    RestangularProvider.setDefaultHeaders({"Content-Type": "application/json"});

or instead ensure the Content-Type is passed with the object:

    Restangular.all('endpoint').post(artistDTO, {}, {"Content-Type": "application/json"}).then(function (response) {}

JavaScript/TypeScript Public Variables

You may be tempted to “object-orientate” your classes (having public setters and/or getters encapsulating private variables for your object attributes). If you’re like me and using TypeScript, and come from a C# background this may be a natural decision to make. Well this is fine for standard objects within your MVC layers, but won’t work for the DTOs you use to communicate with the ServiceStack service layer. Instead, it results in “empty” request objects also. The reason is that when you JSONify your classes, it uses the private variables, which may or may not have the same name


module app { "use strict";

export class ArtistDTO { private _id: string; private _name: string; private _genre: string;

public get Id(): string { return _id; }

public set Id( value: string ) { _id = value; }

public get Name(): string { return _name; }

public set Name( value: string ) { _name = value; }

public get Genre(): string { return _genre; }

public set Genre( value: string ) { _genre = value; } } }

This results in a json format of:

ArtistDTO { "id": "1", "_name": "Tom McRae", "genre": "tortured troubadour" }

To resolve this issue, simply use public variables instead.

DTO Attribute Case Matching

In order for the serialization to work properly, ensure your client-sided DTO attributes match the case of your server-sided DTOs. Otherwise you’ll have those “empty” Request DTOs on the server side or “empty” Response DTOs on the client.

If you want to follow the case conventions for each of the javascript/typescript & C# languages, where the client side DTOs will have camelCase and the server side will have PascalCase then you can set a global variable in your ServiceStack AppHost to convert on your behalf:

JsConfig.EmitCamelCaseNames = true;

These are the ones I have compiled so far in getting ServiceStack and RestAngular to work together. While this might seem worrying to anyone from the outside looking in, we have to remember that RestAngular is a relatively immature and open source project. To put it in perspective, I’d still much rather deal with these issues than working on another WCF project.

If anyone has any more gotchas on ServiceStack and/or RestAngular, I’d be delighted to read them.

Share or discuss this blog post with me on Twitter

thunk Software is a trading name of Kavand Ltd, Company Registration No. NI671803

Website template by Stackrole