Windows Azure Mobile Services Custom API support

This post recaps how to create and consume Windows Azure Mobile Services Custom API. In general Windows Azure Mobile  services (=code name ZUMO) is a cloud related technology which enables very easy consumption of the cloud data from mobile devices. The nice thing about this technology is a support for almost every mobile platform.  
Following table shows few interesting URL, which might help you to start with Mobile Services.

Tutorial: http://www.windowsazure.com/en-us/develop/mobile/tutorials/get-started/ Windows Azure Mobile Services Introduction: http://www.windowsazure.com/en-us/develop/mobile/ Custom API: http://blogs.msdn.com/b/carlosfigueira/archive/2013/06/14/custom-apis-in-azure-mobile-services.aspxhttp://www.windowsazure.com/en-us/develop/mobile/tutorials/call-custom-api-dotnet/

With this technology You can really create a small mobile applications in minutes. Assuming, that you are more or less a good developer, not necessarily a professional.
This was and is exactly the goal of Microsoft. Every developer with knowledge of any mobile platform should be able to build apps which
consume the data in the cloud.
However from scientific and software engineering perspective is this not a big deal. Enterprise and professional developers need usually more.
From the very beginning of this platform, I was concerned about scenarios which Windows Mobile services can support at all.
As a enterprise developer this platform helps me to build applications which are in fact built on top of client server pattern, which was popular in late 90-tees.
However, in this century we learned to leverage the power of services for many good reasons. And now ZUMO seems to push us back to the past to leverage client/server again?!
This was a very first thing I was concerned about. Anyhow, don’t understand me wrong. This platform is limited from engineering perspective, but most mobile apps are very simple apps,
which do not require any special engineering. Accepting this statement as a fact, this technology offers many good things :

1. Simplicity, Simplicity,…, Simplicity
2. Cross-Platform compatibility (Access data (and more) from any mobile platform)
3. Ability to use web as it is to consume the data. (No firewall tweaks required)
4. Easy way to build multi-tenancy (out of scope of this post)

Usually it is not very easy to securely enable access to data which is stored in some cloud database. Mostly you need to invest some time to adopt the infrastructure to make this working.
It sounds crazy, but development of most apps take shorter than creating infrastructure around the app. This is where the cloud computing becomes a good thing, at least.
Most business departments do not even try to innovate software, because they are blocked by IT department processes, which are often, very expensive and complex. This is where cloud computing can be a true choice.

But even if ZUMO gives me few advantages, I still was very limited by simply making app which just deal with raw data. I needed more than simply write and read data on top of client/server model.
There many services out there which do crazy things and touch raw data in just few scenarios (EMail, SMS, calculations, Creating of QR code, etc, etc).
I wanted to implement apps, which are simple, but they might be a simplest and coolest part of very complex enterprise system. My typical requirement looks like I want to run my services on top of Windows Azure Mobile Services platform. So, I want to be able to invoke service operation instead of saving something in DB. My service operation can implement lot of logic before the data is saved.

https://mymobileserviceservice.azure-mobile.net/api/myapi

The framework behind API will automatically route GET and POST requests to corresponding endpoint. The Mobile Service platform will automatically generate two Java Script functions around that name.
If you want to learn more about this API take a look on this post.

For this post, I have created the API sampleapi1. The reason why I peek JavaScript is simple. .NET custom API is right now not supported by Mobile Services platform.
As already mentioned every API provides one POST and one GET endpoint by default. Independent on how your function is called the implementation looks like shown below:
 

Because the API is built as a REST service API style you can add few more endpoints. Following snippet shows which functions are right now available:

If you want to invoke for example GET and POST functions of your API you will need to send GET and POST requests respectively to following URL:

https://mymobileserviceservice.azure-mobile.net/api/myapi

If your API is called sampleapi1 then the request would look like:

https://mymobileserviceservice.azure-mobile.net/api/sampleapi1

Note that mymobileservice is obfuscated name of your mobile service namespace and myapi is the name of api.
Please do not forget to append the header X-ZUMO-APPLICATION, which holds the application key. This header is mandatory for authorization as you will see in the next example.

Let’s now show how to invoke GET and POST endpoints. To do that I will use Fiddler composer to create the request as shown below:

Note that {"message":"Hello World!"} is returned as a JSON payload. This is exactly what the GET function is supposed to return.

To send a POST request, simply change GET verb to POST verb in composer and append some JSON payload.

This request will send a JSON object:

{"Arg":"Hello POST request sample!"}

The response will in this case look like:

At the end note that default permissions are used in these examples. That means that any user of the app can call the custom API, because his app uses application key. 
But note, the application key cannot be considered a secure credential. Because of this, consider restricting access to authenticated users on operations that modify data.

This is more or less all you should know before you start with Java Script API.
You want to know more about Windows Azure and development for Windows? Follow me on twitter: https://twitter.com/ddobric