Monthly Archives: March 2013
You’re planning a new system, and already decided that you want the data to be hosted on the cloud.
Now, should you use web-services? REST (using WEB-API for example)? maybe Windows Azure Mobile Services?
Let’s see the differences between these technologies, but first- a short overview:
The old and well-established type of remote operation mechanism, allowing you to expose your server application’s abilities and services using SOAP-XML contracts that can later be consumed by every client app capable of encoding and decoding XML messages.
This mechanism is platform-independent, and if you stick to basic SOAP-XML structures you can have clients running Microsoft operating-systems, Apple’s, Android or anything else working against your server application, having SOAP-XML as the lowest-common-denominator and the language spoken between your server application and the clients.
XML Web-Services may (and usually will) also supply metadata (WSDL/UDDI) that allows clients to work with your application server without any previous knowledge or information about the server application’s API structure or technology, and may also adapt to API format changes quite easily.
This type of services are cross-platform, self-explanatory, mobilizes well structured data and supports additional communication layers such as WS-Security or WS-Addressing.
“REST” (stands for “representational state transfer”) uses a much simpler approach than XML Web-Services.
While XML Web-Services rely on HTTP or other types of transport layers to send and receive XML messages to and from the server, REST goes back to the source and uses the HTTP command verbs themselves to perform operations and transfer information to and from your application server.
This protocol is much looser than XML Web-Services and will attempt to deduce what operation to perform and how to use the transferred parameters from the HTTP VERB and URI used.
The actual data can be transferred in any format, such as XML or JSON and is not bound to comply with any type of pre-defined protocol.
REST is light-weight, portable and easy to consume by HTTP enabled clients. You can have your service up and running in practically no-time.
On the other hand, though these services may also be self-explanatory (using “WADL”), REST might be less suitable if you require a more strict service API approach, defining exactly what operations to perform and the data to be transferred.
Also, additional communication layers are not supported, beyond HTTP and HTTPS.
Both XML Web-Services and REST services can be hosted on Windows Azure quite easily, and can both be accessed by mobile clients.
Azure Mobile Services:
Windows Azure Mobile Services is a set of Windows Azure services exposed as a pre-defined set of WEB-API hosted REST services designed to be consumed by mobile clients.
When creating mobile services, you can use the Windows Azure wizards to also create Windows 8, Windows Phone 8, Android or iOS client apps, already set-up to connect to your service using dedicated libraries for each platform.
The server is created for you, pre-defined to manage data on the cloud, manage users and authentication, schedule maintenance scripts and custom logic and integrate push notifications.
Azure Mobile Services biggest advantage is that it takes most of the common aspects of the design, coding and testing of the application server and mobile clients off your hands and allows you to focus on the custom features only.
“So, what should I use?”
Well, if you’re application server is intended to serve older/existing XML web-service clients, XML web-services are your only hope, though you might want to consider adding a REST interface to your application server as well.
But, if you are planning an application server that is intended to serve mobile clients, there’s no reason for you to re-invent the wheel when Windows Azure Mobile Services can have you kick-started very quickly with many aspects of the application server.
Moreover, whenever you are required to create the complete solution you can use the Windows Azure wizards to have your client apps already created (for all supported platforms) and set-up to use your application server.
As these services are exposed using REST, you can also have your application server accessible for other types of clients, just like any other REST application server, consulting the Windows Azure Mobile Services REST API Reference.