Introduction

Mobile First is a term often used to describe an approach to application design, usually centered around the presentation layer and the user experience. From UXMatters: “mobile first means designing an online experience for mobile before designing it for the desktop Web—or any other device.”, with the contention that you get a better overall design by following this approach.

There is an implication with Mobile First, although seemingly not discussed nor explicitly called out by those who write about it, which is that you can take a Mobile First approach for all layers in the technology stack, not just the UI. To show this to be true, I’d like to talk about one specific case. Namely, the applicability of a Mobile First strategy to the design of Web Service APIs.

This article is going to talk in the language of HTTP and RESTful Web services.

Who Should Care, and Why?

You should care about this topic if you are involved in the creation of Web service APIs, or you are involved in the evaluation of Web service APIs for use in your applications; be that as a developer, product owner, business stakeholder, project manager, or the like.

Gone are the days where mobile devices are a minor adjunct to the desktop and where applications are, for the most part, conceived with monolithic designs, both in terms of the technology stack they are built on and the experiences they offer to users. It does you no good to have a well-designed responsive user experience if other elements in your technology stack can’t accommodate it.

The fact that mobile devices are the most constraining form factor is what makes Mobile First work. Constraints force you to simplify and modularize, which produces better designs. It is easier to add to a highly-constrained design than it is to subtract from a less-constrained design.

The Mobile Constraints

Before we can talk about what it looks like when a Web service API has followed a Mobile First strategy, we need to understand the characteristics of mobile devices that place unique constraints on the design, above and beyond the traditional desktop. Services that have been designed first for mobile will have taken into account these constraints. Among them…

Not “Always On”

Devices will have unstable internet connectivity at times. Users may have an expectation that your applications can gracefully deal with this. E.g. Work while offline.

Shifting or Limited Bandwidth

At times, a mobile device may be on fast wifi or 4G cellular, or it may be on a near dial-up EDGE connection. And it may be switching between different types of connections as the device travels. Users are not going to be pleased when they have to wait for data.

Limited Data Plan

With data limits imposed by cellular contracts, users may pay close attention to how much data each of their apps are using. Users will not be pleased with applications that do not respect their data plan.

Limited Battery

With heavy usage and limited battery life, users will not look favorably on applications that appear to use more battery than they should.

Limited Memory

Mobile devices inherently have much less memory than desktop systems. Users may be inclined to uninstall applications that appear to be using too much memory.

On The Move

Mobile devices are, well, mobile. They may change their geo-location, move across time-zones, or change IP address at any time; and users will expect applications to accommodate.

With these constraints in mind, let’s take a look at the traits of a Web service API that has taken them into account.

Traits of Mobile First Web Service APIs

As a result of the constraints presented by mobile devices, a Web service API should exhibit certain traits. Note: These are not all the traits that a web service API should exhibit. They are the ones driven by the constraints of mobile devices. Among them…

Paging & Filtering

Let applications request paged and filtered subsets of collections, so that they can retrieve only the records they need or so they can retrieve lists in batches.

Field Selection

Let applications pick the fields they want in a response, so that they can reduce payloads by excluding data they do not need.

Embedding

Let applications indicate whether or not related (linked) resources should actually be embedded in a reply, so that they have more control over payload size and the number of service requests required to fetch the data they need.

Polling Optimized

For situations where data might change frequently and applications are inclined to frequently poll for changes, allow them to conditionally retrieve data, so that they can avoid unnecessary transmission of data. E.g. Take advantage of HTTP’s built-in support for this, via ETags and Last-Modified-Date response headers, in combination with the If-None-Match and If-Modified-Since request headers.

Additionally, where appropriate, consider implementing a server notification scheme, such as WebSockets, whereby the server can initiate communications with applications when data has changed, eliminating the need for applications to poll.

Retries

Allow applications to re-submit data in a way that will not cause duplicate records on the server, so that they can get their data saved when there are connectivity problems. For example, allow an application-generated “request id” to be sent along with each service request. In this way, when the application sends a request but does not get a reply, they can re-send the request (with the same request id) and the service can use that information to determine duplicate requests.

Lightweight

To avoid heavyweight services, use a lightweight data format like JSON (not XML); make services small and single-purpose; provide links to related resources; provide a way for the application to embed related resources when they so desire; and compress responses using something like gzip.

Ubiquitous

Allow the services to be used by a multitude of applications, regardless of programming language or platform. E.g. Adopt a RESTful approach. Avoid service APIs that require an SDK (although SDKs as an adjunct are great). Avoid services that use bulky protocols like SOAP.

Cacheable

Tell users how your data may be cached, so that they can avoid having to re-fetch data when they don’t need to. Take advantage of what HTTP has to offer by using HTTP cache headers.

Partial Updates

Through a mechanism such as the HTTP PATCH verb, support the ability for applications to do partial updates. That is, allow the application to send a partial representation of a resource. This is opposed to the HTTP PUT verb, which is full replacement.

Pings

Sometimes it is handy for a user to simply ask the services if they are alive, or to fetch service metadata (such as the HTTP headers) without having to fetch actual data payloads.

Location Aware

Given that mobile devices can be on the move, services should never assume that a device’s location is static. If geo-location or time zone information is important, then make sure your API accounts for this by providing a way for the application to transmit this information.

Examples in the Real World

Let’s examine a few public-domain RESTful service APIs to see how they stack up against the Mobile First traits…

	Github	Facebook	Twilio
Paging & Filtering	yes	yes	yes
Field Selection	no	yes	no
Embedding	no	yes	no
Polling Optimized	yes	yes	no
Retries	no	no	no
Lightweight	yes	yes	yes
Ubiquitous	yes	yes	yes
Cacheable	yes	?	?
Partial Updates	yes	yes	no
Pings	yes	?	no
Location Aware	yes	?	yes

Summary

Designers of Web service APIs should use a Mobile First approach, so that the APIs are well designed to meet the constraints of mobile while still being designed well for the desktop or other less-constraining form factors.