Which approach to use for your data APIs: generic or specialized?

Your API lets you concentrate all your frontend-backend interactions through a single channel. But with more and more diverse client devices and objects, is having one, generic API still the best approach?

railroad turntable
Credit: By Gnsin (CC BY-SA 3.0)

Data APIs are rapidly becoming a favored conduit for frontend systems -- websites, applications, and mobile apps, but also connected objects -- to gain access to data served by their backend systems. The gains of using APIs are many, among them the ability to properly distribute data between backend and frontend.

Nevertheless, the continuous increase in the diversity of consuming devices and objects is requiring architects to rethink the way APIs were originally designed.

Is the reign of the generic API over?

The original intent of building a data API is to reduce the number of entry points into the backend system and streamline the development and maintenance of interface resources. An ancillary benefit of this reduction in the number of interfaces is that having a single API makes it easier to administrate, to secure, to control and to monitor.

As a result, most data APIs have been designed and built as a complete set of resources, some of them are used by many (all) frontend clients, some of them used only by specific clients for specific use cases. In more and more cases however, the introduction of a client-specific feature requires an addition or change to the API, that does not apply to other clients. For example, Apple's Touch ID for authentication is an iPhone-only capability, and the backend service and API resource you have to implement to enable its support is completely useless for any other client device.

One thing you don't want to do however is to start breaking down your APIs by feature: for example, build a "side API" for Touch ID that only the iPhone app would call. This would very quickly make the whole system impossible to maintain and administer.

The device-specialized API

A better approach is actually to break down your data APIs by consuming device. Instead of deploying one single API that all devices call, deploy one for iPhone clients, one for Android clients, one for Web/HTML5 frontends, one for screen-less connected objects, etc.

Each of these APIs will have a lot in common with the others -- it can (and should) share backend logic and code. But the data transfer strategies, dataset filtering, and even which backend functions are available to call, will differ from API to API. For example:

  • You can't show the same amount of detail about each item on a phone screen and on a tablet screen. Therefore, retrieving less information and smaller images will improve response times and decrease data consumption.
  • For a non-GPS-enabled device, providing geocontextual information is useless, and requesting coordinates that will return an error code, a waste of time.
  • For clients that are always connected (such as Web frontend), data preloading and infinite scrolling strategies should be different than on mobile devices.

Beyond the improved performance that specialized APIs will bring, the impact is also high on application lifecycle and release agility. When you support dozens, or even hundreds of different devices, aligning the release of all clients apps, backend systems and of "the" (generic) API on the same schedule is close to impossible and certainly does not bring agility to quickly support new features or capabilities of devices and their OS.

Conversely, the lifecycle of a device-specialized API can be closely aligned with the lifecycle of the app or device it is serving, accelerating the go to market of new capabilities and the attractiveness of the system. Adopting a design-first, or API-first development strategy is also part of this agility.

But it certainly adds new constraints, and may also complexify the management of the system as a whole.

This article is published as part of the IDG Contributor Network. Want to Join?