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.
With heavy usage and limited battery life, users will not look favorably on applications that appear to use more battery than they should.
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.
Let applications pick the fields they want in a response, so that they can reduce payloads by excluding data they do not need.
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.
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.
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.
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.
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.
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.
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.
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.
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…
|Paging & Filtering||yes||yes||yes|
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.