Mobile Apps: Geolocation using Web Services

2011-12-19 17:33 by Sören Kunst

Because mobile devices and their apps are now an inherent part of our modern society, popular web-applications need to support given hardware features of these mobile apps. For example how good would popular networks such as Facebook and Twitter be without a smartphone app?

This Case Study is covering high-level use of the RESTful Web Service for geolocation. Furthermore Scalability and Performance of the RESTful Web Service are discussed.


Mobile Devices and Geolocation

Today, most mobile devices come with hardware features like a microphone, camera and geolocation.

With an app on a mobile device leveraging these features it is now possible to record audio, take photos, videos and send them all to a web-application on a server. But even more exciting is leveraging geolocation capabilities, like GPS or Wi-Fi location to provide location-aware features on the web-application.

Imagine a recommendation system that shows the nearest restaurants and notice if there is a promo in a pub just a few steps away. Sounds great, doesn't it?

With an app on a mobile device, highly accurate user position data can be recorded and saved in a database on a server, probably using a geographic-specialized module like PostGIS. Why are "spatial databases" needed though? Because, it allows the use of highly-efficient indexes designed especially for geographical searches. Furthermore, some special functions for distance or area calculations can be utilised.


The RESTful Web Service

One problem that needs attention is how to move the data collected by the app to the web-application. This is where the RESTful Web Service comes into play.

The implemented solution provides CRUD (Create Retrieve Update Delete) based on HTTP methods. We use pretty, self-explanatory URLs and the OAuth authentication method.

Look at the restaurant’s recommendation system example. Users would be allowed to manage their favorite places, e.g. pubs, restaurants, coffee shops or others. A user should be able to get their position, enter place's metadata, maybe add some photos and send these data to the server. How? Using a HTTP method based CRUD, for example:

GET /places               # get places list

GET /places/name      # get a single place

POST /places             # create a new place

PUT /places/name      # update a place

DELETE /places/name  # delete a place

The code listing shows URLs patterns and HTTP methods used to provide full CRUD mechanism for a place objects management. How to use it? A HTTP request is needed to a given URL using the appropriate method. If necessary any additional data should be passed in the request body. For example, to create a new Place object, a request using the POST method should be made. Put the place name, address and telephone number in the request body and pointing it to the “/places” URL would be needed. It's simple and effective! And even more important, it's highly accessible –a wide range of software and devices can be provided with it, from your web browser to a smartphone.

What else has the RESTful Web Service to offer?



The RESTful Web Service was made to be stateless. Given that, all necessary context and parameters in each HTTP request headers and body will be sent, so the server does not need to know anything about the client state between requests.

What does that mean? Well, if scalability is required one can easily build a cluster of servers with a load-balancer in front of them and redirect subsequent requests to whatever server that has capacity at any moment. No more tying up to one server during one session or enforcement to replicate this session, because there is no session at all!

Thanks to that we're able to build a highly scalable and reliable architecture more effectively.



Processing a lot of requests containing full context can be resource extensive. The stateless nature of RESTful Web Services really helps in these situations but nevertheless it is best practice to provide some in-memory caching mechanism.

The described web-application has to handle hundreds of API requests per second, mostly geolocation related. Moreover, these data weren't modified very often. So instead Redis was used to cache those. Redis provides a replication feature out-of-the-box. Redis also allows persisting the cache to some non-volatile memory. That means that in case of any issue we can always restore the cache with a state from the past.



Mobile devices are not only the future of IT systems, they are the present. Valuable experiences with knowledge and practical experience on how to leverage mobile devices was made. Also, highly-scalable and high-speed REST APIs with in-memory caching to support mobile applications was provided and maintained.

If you have any question, don’t hesitate to connect with Soeren at UWS Software Service. 

See what we can do for you:

Grails Developers

Java EE Developers

Java Outsourcing

Go back