Two engineers viewing a plan

Three Very Different Categories of APIs

API architecture is powerful because it provides a simple, predictable interface that can overlay complex systems and make them universally accessible. Because APIs are so powerful, they’ve been put to use in many different scenarios. There are three basic categories, which we discuss below.  

The Single Implementation API

Also known as “Backend-for-Frontendâ€, or the BFF pattern, this category of APIs is the newest we’ll discuss. Two major trends in technology are driving use of BFF APIs. First, moving apps to the cloud lets developers replace heavy client-side applications with web interfaces. Second, the growth of mobile devices in the workplace is booming, including in industries like construction that previously had little tech penetration in the field. 

In theory, it’s possible to have a single API that connects all devices and all microservices. In practice, APIs that try to be all things to all users wind up bloated and resource-intensive. BFFs help meet the demand for lightweight mobile applications, matching each device interface with its own version of the API. 

BFFs can mirror each other, with several similar APIs adapted to different frontend interfaces, each executing the same stack of functions. Or they can serve as gateways to a centralized service, with most of the backend functionality in the shared resource. BFFs require maintaining duplicate code in multiple APIs, but can optimize for different use cases.

The Internal Utility API

Microservices, which we mentioned above, are behind almost every interactive web application. A microservice API simplifies a key piece of functionality down to its inputs and outputs and detaches it from the rest of the code base. Developers can refactor, test, and deploy changes to the microservice without touching any other application code.  As a microservice grows in complexity, it can be split up into multiple services, requiring only small changes to other parts of the codebase.  

Software used to be updated and released on a fixed schedule, with many changes bundled into a single new product version.  The shift towards CI/CD (Continuous Integration/Continuous Deployment), where product updates are released as they are available, required a change in how different functions of an application are integrated and led to Microservices architectures.

The External Extension API

External extension APIs are what most people think of when they think of APIs – public-facing interfaces to a data set or service. The main purpose of an external extension API is to separate backend functionality from frontend applications. 

Providing users direct access to backend functions allows flexibility and innovation in how data and services are used. Consider the difference between a link to the Google Maps website versus an integrated map widget that uses the Google Maps API- the hosted UI is very useful for general purposes, but when a developer wants to overlay custom data on a map, the API is a much better tool.  

Some external APIs are designed for integration into applications, and don’t offer any user interface of their own at all.  This category includes many SaaS products (Software as a Service), like testing suites and search tools.

These three categories of APIs are responsible for much of the complexity of the modern web!  APIs simplify access to data and make using software services easier, faster, and more reliable.