Along with data cap and battery drain, speed is a top usability issue for most mobile device users. Even using the latest 4G LTE, mobile networks inherently have higher latencies than DSL, and devices still experience slower ping over WiFi.

The protocol, device configuration, or app design can all contribute to these slow load times. As there are plenty of performance limitations still inherent in mobile, the software and integrations need to be constructed with these limitations in mind. So, what is it like designing APIs specifically catered to a mobile setting? How can providers optimize their API to help app developers reduce latency and deliver customized data?

In this article, we’ll learn how to design low latency application programming interfaces (APIs) optimized for mobile applications. We’ll explore the mobile communication industry, consumer expectations, and offer methods to optimize an API for mobile by implementing expansion, data subsets, compression, pagination, and a mobile facade.

Latency

What is latency? Latency is the time between the moment you request data till the moment you actually start receiving it.

When you are requesting a large amount of data, such as a 50MB request, the amount of time it takes to establish a connection (ping!) may be insignificant in comparison to the transmission of the data package itself. In contrast, however, the initial latency is far more significant if you’re dealing with small requests, actually making up most of the total processing time.

If you take a look at different mobile connections across the market, and how a single ping works, important KPIs to consider are the average and standard deviations across different protocols. Below are global average connection times points for various protocols, based on data collected by CISCO.

The Market

Though the sales of 4G smart phones hit 58% market share in 2015 Q1 we shouldn’t completely disregard 3G, or even 2G. The fact is that the deployment of LTE networks is well under way, but it is expected to coexist with 3G and even 2G networks for years to come. According to further projections by CISCO, connection speed world-wide market share may look like this in the coming years:

Throughput

An equally compelling concern in mobile app development is throughput — how much can be processed within a certain period of time. Dwarfed by Teraflops processing of supercomputers, mobile networks must operate on the Megabytes per second level — Mbps.

Though a device’s bandwidth — the theoretical maximum consumption rate — may be theoretically high, throughput is the rate of successful data transfer. This can be significantly dictated by geography (as seen to the right), as well as distance from cell towers, network congestion, and interference due to weather or building materials.

Dependencies such as 3rd party SDKs or APIs can have significant effect on overall speed as well. According to AT&T Best Practices for 3G and 4G App Development —

“A common aspect of modern mobile app development is the use of drop-in components like advertising SDKs, analytics SDKS, and map controls. Banner ad controls have been observed to have a significant effect on uncontrolled network traffic; analytics engines and maps may be communicating with their respective back-end services outside of the direct control of the developer. Therefore, it can be useful to analyze and understand the types of traffic and the patterns of data use that these controls introduce into your app.”

Methods to Optimize an API for Mobile Consumption

While the old is certainly being replaced, we still need to develop with these slow speeds mind. Catering to a mobile environment means, whenever possible, limiting data being sent to the bare minimum. In order to circumnavigate high latency and low throughput scenarios, and to optimize for general mobile use cases, there are several things developers can do to tweak the way their API behaves.

Merge Responses

Don’t provide entities the way they are structured on the backend — focus on balancing simplicity and complexity, and scale your API response to only what the user is intending to display. In this case, it helps to have a close relationship with the teams creating the mobile application so as your API can be augmented to their specific needs.

Expansion

If you aren’t working closely with developers creating the mobile application, resource expansion is a great mechanism to return customized fields. Using hypermedia, linking, and resource expansion can allow customized responses that can decrease latency and data.

Let developers decide what they want to present. This theory is even more applicable in large data collections, where going beyond a GET /people/ call to offer querying of specific fields like GET /people?fields={firstName, lastName} can be helpful to offer fine grained options and reduce data return size. A problem with expansion that Erbetowski sees is that there are no good tooling options — no big frameworks support it out of the box — complex queries for nested entities need to be hardcoded.

Data Subset

A common scenario is that you are providing a single API to work within both a browser as well as supporting a mobile application. Whereas a browser with a low latency and high throughput can handle large data easily, there may not be enough space to present the same this data within a mobile app. More likely, the user experience will be altered to the limitations of the device. Erbetowski recommends providing the minimum data subset for mobile apps. Using hypermedia, provide trimmed versions of your data to mimic page-by-page use case scenarios. Also use pagination with input page number and size so the clients can further determine what they need.

Complete model

{
“person”: {
	“id”: 38385,
	“firstName”: “John”,
	“lastName”: “Doe”,
	“age”: 25,
	“country”: “US”,
	“phones”: {
		“home”: “800-123-2485”,
		“cell”: “800-159-1947”,
		“work”: “800-325-1851”
	}
	“email” {
		“johndoe@example.com”,
		“johndoe@example.org”,
...

Trimmed model

{
	“firstName”: “John”,
	“lastName”: “Doe”,
	“age”: 25,
	“country”: “US”
}

Compress Data

In addition to reducing payload size by using JSON, optimize by compressing data. Erbetowski recommends using gZIP for file compression and decompression of large messages. The only reason when you wouldn’t want to use gZIP is when you have many small endpoints that provide very small amounts of data — gZIP will grow and it will cost you too much computational power than it is worth. Erbetowski cites these examples as evidence, noting that you can cut down a large message size up to 90%.

Case Study: Applause App

As a case study Erbetowski recalls a legacy API used by a mobile application— Applause — that Polidea helped make more efficient for mobile. They ended up rebuilding the entire API, reducing 36 endpoints to 20 endpoints. This means that 16 endpoints included parameters that were used in the same context that something else was. The entire application used to do 86 calls, and was brought down to 20 — one call per endpoint. In general, this reduced data sent to the device by 84%.

In a demonstration, the legacy app using the old API took 21 seconds to load the requested data, while the new one took only 5 seconds to accomplish the same task. Instead of aggregating data locally, the app now only calls the data as it is displayed. For an end user, this redesign dramatically enhances the experience.

Conclusion: Designing in the World of Limitations

Optimizing an API for mobile — the “world of limitations,” as Erbetowski calls it — can be achieved, and you don’t have to destroy your beautiful API platform to do so. Many instances allow for the creation of an API facade catered to mobile. Though LTE brings a general improved quality of service, higher bandwidth, and lower latency, the toolbox on mobile is still pretty primitive. Whether supplying an API to be consumed by third party app developers, or developing an in-house app with an API backend, consider these methods to optimize an API for a mobile setting:

• Merge similar parameters to cater to mobile needs
• Offer fine grained options to reduce data return size
• Provide minimum data subsets
• Compress data using gZIP
• Limit data being sent to only what is being displayed
• Configure a mobile facade