We’ve talked about APIs and the IoT before but in this post we are going to take a look at some of the infrastructure that will be required to provide a mobile API to your IoT service.
It goes without saying that mobile devices have become ubiquitous in our modern lives. Whether it’s a tablet or smart phone, most of us are never far from a connected mobile device. To date these devices have brought us a number of benefits – making services such as telecommunications, the internet and banking (to name just a few) mobile.
But there is now another market where the mobile device is ready to feature heavily – that is the Internet of Things. Although not strictly a requirement for an IoT infrastructure, mobile devices will bring to IoT what they have brought to all other services – convenience of access.
Before we begin it is perhaps worth noting that most of this infrastructure would also be used to implement a desktop API to your IoT service.
Let’s start with the basics.
In any IoT service infrastructure you will have deployed IoT devices – be they wearables or home, office or industrial systems. Via a network infrastructure – WiFi, Ethernet, Bluetooth/BLE, ZigBee, etc – these systems will be connected to backend servers – likely using a communications protocol such as MQTT.
The backend servers will be responsible for processing and warehousing the data passed up from all of the IoT devices. Access to the IoT system will be provided to the user via a user interface – for example, a desktop web interface or mobile application. The de facto IP communication protocol for both desktop and mobile to backend servers is HTTP – meaning you can build out support for both desktop and mobile with a single API.
Of course all of this infrastructure will have to be secure, reliable and scalable. But we’ll leave a discussion of how to build such an infrastructure for a later blog post.
Extending to mobile
With the basic infrastructure in place, let’s look at what we should add to make it more mobile friendly. The major addition any mobile API should leverage is push notification services – all of the major mobile OS vendors provide a push service (iOS has Apple Push Notification Service, Android has Google Cloud Messaging and Window Phone has Windows Push Notification Services).
Push notification systems provide a paging like facility directly into mobile applications. This allows mobile application developers to notify a mobile device when the backend server has data for it – which turns out to be an important strategy when trying to prolong battery life. To see this more clearly consider the traditional (or desktop) based methods for retrieving updates from a backend server.
For desktop applications updates are either provided by maintaining a persistent TCP/IP connection or by long polling. Both of these strategies are well suited to devices with a fixed power supply but are not as well suited to battery powered mobile devices with power hungry wireless interfaces. In the push notification paradigm the backend server pushes a notification to a users device (via the appropriate service). Upon receiving the push the application knows that it must request an update from the server over the HTTP API. In this way a HTTP request is only issued when absolutely necessary.
There are a number of points worth noting about using push notification services: you will need to keep a registry of devices so you know: if it’s a mobile and, what OS it is – indicating which push service to use.
Not all push services guarantee delivery of a push so you will need to be able to retry pushes while push notifications can take a payload, that payload size may be restricted. It may be a better strategy to use push as an indication to issue a standard API request for an update. This also means sensitive data doesn’t have to be passed to a third-party server.
And there you have it. There’s the basics of building out a mobile (and desktop) API for your IoT system. In my next post we’ll discuss building out such an infrastructure to ensure that it is secure, reliable and scalable.