tagged: JSON, mobile development, SOAP, web services

Quick guide: Exposing webservices for mobile apps

Posted by Steven Preston in Web Services

Probably 90% of the apps I’ve written have relied on web services as a means to retrieve content to be used in the app. Since mobile apps are often just a channel or medium for accessing some sort of greater product, a means for these apps to interact with and gain access to the resources of the greater product is generally needed. And where RSS feeds are too one-dimensional to do the job, web services step in.

The quality of web services can impact the development time on an app; as well as the efficiency of the app when retrieving and processing the data – these are things that server-side developers don’t always consider when writing web services. The server environment is very different to the mobile app environment and where multiple calls to a web service might not seem that bad on the server-side, it can be costly on the client-side – particularly in mobile. While you might get away with inefficient web services for apps accessed through a desktop, any issues arising from web services become far more apparent on a mobile device. So here are some tips if you ever need to define a web service for interaction with a mobile app:

Forget SOAP – use JSON or another lightweight format: SOAP is bloated – it can effectively double the data usage of an app. Open source JSON libraries are readily available for every platform and are a no-brainer for web apps using Javascript. Especially if you’re using .NET on the server-side, resist the temptation to write SOAP services and rather go JSON – check out http://json.codeplex.com.

Consistency please: This seems to crop up most often in the formatting of dates in a single web service; but can apply to any aspect of the service. Decide on conventions and stick to these for both the formatting and structure of your data.

Avoid multiple calls wherever possible: If its guaranteed that the app requires all the items in a particular data set, provide a method to retrieve them all in one go. Don’t settle for forcing the app to retrieve each one by one. Managing multiple connections is inefficient. If the data set is large and you want the app to show some sort of dynamic loading to the user then create a method to enable downloading of a variable number of items at once. This way the client-side developer can decide which is most efficient – to retrieve 1, 5, 10 or all items at a time.

But also avoid bloated data retrieval: This is the most obvious of them all but I’ve seen it done – if your data set is large but the app requires small subset only determined at run time, don’t provide only a single method to access all the data. Doing the data processing to identify the required subset will almost always be more efficiently done by the server whilst unnecessary data usage slows down an app considerably and takes its toll on a user’s data bill.

Design the app interface first and then build the web services around this: If you’re looking for how to structure your web services so that they are client-side friendly a good starting point is to analys how the user will interact with this data and what the app interface might look like (this approach can be more complex if your developing a public AP). Often looking at each user interaction with the app will map well to the different web service methods needed rather than simply trying to think of it purely in terms of how you can make the data in your system available to the outside world. Try to provide the app with the data as closely mapped to what the end-user would want to see as possible, whilst exposing the data in a format generic enough to be formatted and manipulated as needed within the app.