Windows Azure Mobile Services Custom API support

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

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.

image 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.


With the new version Windows Azure Mobile Services provides a feature called (Custom) API. Go to management portal, select your mobile services and click on API.
Following picture shows my custom Java Script based function (API) called “sampleapi1””

image
This feature allows you to create your own Java Script function on top of HTTP/REST, which will act as your service. When you create your API you will have to simply provide the name of the API.
This name will become a virtual path used to route requests to your service.

For example if your API is called MyApi, you will get two functions: exports.post and exports.get. around following route:

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:
clip_image004 

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:

exports.get = function(request, response) { ... };
exports.post = function(request, response) { ... };
exports.patch = function(request, response) { ... };
exports.put = function(request, response) { ... };
exports.delete = function(request, response) { ... };

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:

 

 

GET https://mymobileserviceservice.azure-mobile.net/api/sampleapi1/ HTTP/1.1

User-Agent: Fiddler

Host: eventservice.azure-mobile.net

X-ZUMO-APPLICATION: AJbucThROBFUSCATEDheBVcbf69

 


Note that you have to use the verb GET and the right URI, which contains the name of API. In this case sampleapi1
If you do not know how to obtain the right value for this header do following. Go to Mobile Services tab, select your service and click on Manage Keys.
 image
Then copy the Application Key and append it to header X-ZUMO-APPLICATION.

image


After sending of this request the response will look like

 

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Length: 26

Content-Type: application/json; charset=utf-8

Server: Microsoft-IIS/8.0

x-zumo-version: Zumo.Main.0.1.6.4141.Runtime

X-Powered-By: ASP.NET

Set-Cookie: ARRAffinity=3c8a8c3******f98d876901b27b702c4;Path=/;Domain=mymobileserviceservice.azure-mobile.net

Set-Cookie: WAWebSiteSID=********; Path=/; HttpOnly

Date: Tue, 12 Nov 2012 23:53:58 GMT

 

{"message":"Hello World!"}

 

 

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.

 

 

POST https://mymobileservice.azure-mobile.net/api/sampleapi1/ HTTP/1.1

User-Agent: Fiddler

Host: eventservice.azure-mobile.net

X-ZUMO-APPLICATION: AJbucOBFUSCATEDheBVcbf69

Content-Length: 22

 

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

 

This request will send a JSON object:

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


The response will in this case look like:

 

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Length: 28

Content-Type: application/json; charset=utf-8

Server: Microsoft-IIS/8.0

x-zumo-version: Zumo.Main.0.1.6.4141.Runtime

X-Powered-By: ASP.NET

Set-Cookie: ARRAffinity=3c8a8c38d6e85a0ece2b3f7dbc09ce46dde3fcab80e78f98d876901b27b702c4;Path=/;Domain=mymobileservice.azure-mobile.net

Set-Cookie: WAWebSiteSID=fa95effebd464a2cbd39542342bf3739; Path=/; HttpOnly

Date: Wed, 20 Nov 2013 00:21:03 GMT

 

{"message":"'Hello POST Request sample!'"}

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


Posted Dec 11 2013, 06:46 PM by Damir Dobric
Filed under: , ,
developers.de is a .Net Community Blog powered by daenet GmbH.