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 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.

Learn why API Keys ≠ Security: API Keys Are Not Enough

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. The recommendation is 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. Use the 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. 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, 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,” 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