One of the things I like about Azure Mobile Services is how the integration with node.js gives you the ability to quickly generate a compliant REST API along with quickly standing up backend persistence.  Using node.js and the operational triggers attached to each created table, you can very easily perform all sort of data operations and produce common REST like behavior.

A Bit About REST

This is something of a soapbox for me.  REST is not strictly related to web services, it is designed to be much closer to the metal than that.  If we think about web service technologies such as SOAP, we see something that is built on top of HTTP, adding additional overhead to provide additional functionality.  This is different from REST.  REST is about using what HTTP gives us rather than supporting an RPC style web service.  Instead of thinking about calls to the API as functional calls, REST has us think of them as if the user were simply browsing; thus we can rely purely on HTTP for all matter of things.

Take for example, errors.  Very commonly I see developers returning “error” objects from REST; this is, in my opinion, not correct.  HTTP already has errors and error codes, in fact you run into them every day, ala the infamous 404 error.  In a pure REST implementation, if you user was not found you would return a 404 from the server, not an error object.  Your client code would then interpret it.  If the user attempts to access a resource to which they do not have access, the servers returns a 401 (Forbidden).  In short, REST is about using what HTTP gives you, rather than building on top of HTTP as is the case with something like SOAP.

Back to Mobile Services

Azure mobile services provides an endpoint for each table you create.  So if you create a table called “People” you have an endpoint: <a href="http://http://<mobile service name>.azure-mobile.net/tables/People.  Using this endpoint you can send a variety of verbs (POST, PUT, DELETE, GET).  Depending on which verb is used will indicate which node.js trigger is invoked as a precursor to the action operation.  Here is the mapping:

• POST => Insert
• PATCH => Update
• DELETE => Delete
• GET => Read

At minimal, the script must call request.execute() which indicates the operation should be processed.  You can add conditional logic, ie validation, and use request.respond, which will allow you to pass back an HTTP status code along with a message.  In the case of invalid data, you would not call request.execute().

I admit, I find it rather strange to use the PATCH verb over put to invoke UPDATE, it definitely tripped me up when I first started playing with updates.  However, according to the Azure team, because the default functionality does property –> column matching, it in conceivable that a subset of properties could be sent thus “patching” the existing object, as opposed to a full scale update which is what the PUT verb is commonly associated with.

But how does it know?

So you may be thinking, how does DELETE and UPDATE know what to update.  The answer is, the id column.  Each table in Azure Mobile services is REQUIRED to have an id column, in fact it is automatically created when the table is created.  These operations will automatically key off this id.  Here is an example of the URL to the endpoint:

https://pn.azure-mobile.net/tables/Notifications/1

This will update the record in the Notifications table with the id of 1.  You would pass a JSON object in the request body with the values to replace with.

So what is the result?

The reality is REST is designed to work with resources, its not really designed for endpoints per se.  It is designed so you can query a resource in different ways and perform actions based on those verbs.  With that in mind, I really find what Microsoft is doing with Mobile Services very cool.  Not only do they provide a backend that is easy to work with, they are also allowing developers to quickly implement REST API on those tables/resources using node.js.

For reference: http://msdn.microsoft.com/en-us/library/windowsazure/jj710108.aspx