Adding custom WebApi controller to Azure Mobile Services

Azure Mobile Services supports multiple ways to exchange data with client apps.

A very powerful way is WebApi. It’s just the same solution as the WebApi found in Asp.Net (MVC), it just another endpoint which can exchange JSON messages in a Restful consumption format. The WebApi supports Get, Post etc.

But if we look at the two flavors of AMS, the JavaScript back-end and the C# backend, the first one is configured in another way compared to the last one. In the Web portal of the JavaScript version, the logic can be added as a script.


The users of the C#  backend do not have this opportunity. The API tab is completely missing. How do you add some WebApi controller?


Well, just as with all logic to be added to the C# service, open the Azure Mobile Service solution in visual studio. And although there is a map named Controllers (containing a sample TableController), just add an extra map named API.


Then right-click the map and select sub-menu Add | Controller, just like in Asp.Net MVC.


And there we have a broad selection of possible controllers. Let’s ignore the TableController and let’s compare the Microsoft Azure Mobile Services Custom Controller with the Web API 2 controller. So select the first one and add it.


Although the map named API was selected, the new controller is added to the Controllers map.


A full working example was generated. So if we look at the code of the custom controller, we see the extra property named Services.


This property gives us the possibility to access some features of the Azure Mobile Service in runtime behavior on the server. Here the code generated by default , adds a message to the server logging.

Let’s look at the other type of template.

Again select the map named API in the Solution explorer. Now let’s add the WebApi 2 controller.


This time, the controller is added inside the map selected. That’s promising.


So we put a controller outside the map named controllers? Relax, this will work! I like to separate my API controllers from the Table controllers. Somehow (with reflection) the service will find the controllers and make them available. And see, the new controller is derived from the same base class.

But the WebApi 2 controller is pretty empty. so let’s add some logic.


Here a few interesting changes are made. First, we see the same property  named Services is added. Because we want to log and this will also give access to information about the user currently doing the call (only if we have user authentication activated), we need this property.

And this controller exposes a POST action, not the default GET.

We receive an integer as a parameter. And we expose a list of custom classes (TestResponse) as a result. We fill the list with one instance and that one contains both the name of the SQL server our data context is using (a reference to System.Data was added) and an integer.

Note that the public properties of the class, used in the result, is having attributes added for the JSON notation.

So deploy the service and check the available help pages for the service for reference.


And yes, both API services are available and see that for both the path in the endpoint is the same. Hurray for reflection!

So open up a client XAML page and add a button to consume an API controller.


In the onclick event we put the following client code.


On the service client, we call the method named InvokeApiAsync and give it information about the API to consume (note the “Controller” part of the controller name is omitted). We specify the kind of call (GET, POST, etc.) and we pass the ID parameter as part of a dictionary with a string key and a string value.

And most important, we specify the result we expect to receive. Therefor, we need to have the same result class client side as we have specified server side. This class is needed so the client instance can map the receiving JSON data on instances of that class.

In this example, the result class is specified again. Of course, it’s better to specify it in one common library and reference that library both on the client and server.

You are ready to consume now. Start the client app and see you receive the API controller result. This result should be a combination of the number 84 and the server name of the database context.


In case you see local DB as the database server, you are consuming the localhost version of your Azure Mobile Services service. Close but no cigar 🙂


This example will give you a flying start while exchanging data between server and client.