Partilhar via


Azure Mobile Services REST API

Although Azure is a Microsoft product, it has made huge strides to be able to support whatever platform, code base, and tools you choose to use.  For instance, on the developer side, there are native SDK’s for Azure Mobile Services for IOS and Android development on top of the SDK for Windows dev that you would expect.  This means, regardless of which mobile platform you are targeting, you can use Azure as your universal mobile cloud backend.  In addition to access to the native SDKs for Azure Mobile Services though, you also get access to the REST API.

The REST API end points are created for you when you create your mobile service, so you don’t have to set up a thing.  For creating your first Azure Mobile Service, you can follow my previous tutorial, Creating An Azure Mobile Service.  With the REST API, you get access to CRUD operations (Create, Read, Update, and Delete) on the data in your tables.  To learn how to create a table in your mobile service, you can follow this tutorial, Adding a Table.  In dealing with your table and CRUD operations, you can authenticated requests by either the Application Key for your Mobile Service or via 5 different providers (Facebook, Google, Twitter, Microsoft, or Windows Active Directory).

The first thing we need to understand with the REST API is what the base URL looks like.  The base URL is going to be the Mobile Service URL found in your dashboard.  I point this out to you in Creating An Azure Mobile Service.  if you need a refresher, login to your Azure account, click on your mobile service, scroll down a bit, and you should find your Mobile Service URL on the right hand side.  Again, this is the base URL for any call you will make.  To perform operations on your table, you will tack on /tables/<table-name> to your base URl.  Let’s take a look at these four operations. 

**Note**  With each Azure Mobile Service you create, the portal gives you the opportunity to create a ToDoItem table and a sample project to interact with it.  The examples below will be focused on using that ToDoItem table.

Query

To perform a Query on our table, we can use a simple HTTP GET request in whatever language we are using.  We can also pass in URI Parameters to filter, order the results, etc.  You can find the full list of parameters here, https://msdn.microsoft.com/en-us/library/azure/jj677199.aspx.  Below you can see the structure of a simple Query request.

HTTP Verb – GET https:// <service_name> .azure-mobile.net/tables/ <table_name>

If we wanted to filter our results to only get results that have the complete property is set to true, we could use the following request.

 GET https://todolist.azure-mobile.net/tables/TodoItem?$filter=(complete%20eq%20false) 

 

Insert

Insert is very similar to Query except that instead of using HTTP GET, we use a POST request.  The only other difference is that we actually have to include the item we wish to insert into the body of our POST request in JSON (JavaScript Object Notation) format.  See the below example for adding a new ToDoItem to our table.

HTTP Verb - POST https:// <service_name> .azure-mobile.net/tables/ <table_name>

Sample ToDoItem to include in the body of your request.

 {"text":"Complete the tutorial","complete":false}
  

Update

To update an item in your table you must know the ID of that item and tack it on to the end of your request string as below.

HTTP Verb PATCH https:// <service_name> .azure-mobile.net/tables/ <table_name> / <item_id>

Then, similar to an Insert, include the updated record or property in the body as a JSON string as below, which updates the completed property of the item to true.

 {"complete":true}
  

Delete

Delete is similar to Update in the sense that you need to know the ID of the item you wish to delete and include it in your request string.  Since you are deleting the item and not updating, you do not have to include an JSON string in the body.

HTTP Verb DELETE - https:// <service_name> .azure-mobile.net/tables/ <table_name> / <item_id>

You’ve now seen a simple example for each of the four CRUD operations above, but you might be wondering, how do we authenticate users?  With each of the above call, you can add Request Headers to handle authentication.  One  way to handle authentication is to only allow requests that include the Application Key.  If you need a refresher on what the Application Key is and/or where to find it, you can read Creating An Azure Mobile Service.  To include the Application Key in a request, you would use the following Request Header.

X-ZUMO-APPLICATION

In addition to authenticating via the Application Key, users can also be authenticated via the 5 different providers mentioned above (Facebook, Twitter, Google, and Microsoft).  To be able to use these options, you will need to configure your identity, https://msdn.microsoft.com/en-us/library/azure/jj591527.aspx.  To begin authentication, you would make the following call.

HTTP Verb – GET https:// <service_name> .azure-mobile.net/login/ <provider>

The provider tag will represent which of the five authentication providers you wish to use, shown below.

 

facebook

Requests a login by using Facebook as the identity provider.

google

Requests a login by using Google as the identity provider.

microsoftaccount

Requests a login by using Live Connect as the identity provider.

twitter

Requests a login by using Twitter as the identity provider.

windowsazureactivedirectory

Requests a login by using Azure Active Directory as the identity provider.

 

A successful response from the above call would look like this that includes a JSON Web Token.

https:// <service_name> .azure-mobile.net/login/done#token= <jwt_token>

You would then use the code to authenticate the user.  The code can be include in the following Request Header

X-ZUMO-AUTH

 

So, there you have it.  With Azure Mobile Services, you not only have access to Native APIs for Android, IOS, and Windows, you also have access to your data via a REST API, which is created for you.  This was not a hands on tutorial, but hopefully after reading, you get a good understanding of how to leverage the REST API available to you.  As always, if you have any questions, comments, or concerns, please comment below or find me on twitter @jamesqquick.