How the API principles of abstraction benefit API providers

This is the fourth part of our series What Are APIs and How Do They Work? In part 3, we went deep on how Web and browser APIs make the Web programmable while fueling what’s known as the API economy.

When an API’s endpoint is architecturally the point at which the API-consuming application is essentially decoupled from the service being consumed, it affords the API provider a significant amount of flexibility when it comes to providing its service.

We have been using electricity and electric sockets as a metaphor for APIs, and the comparison stands here, too: As long as the electric company continues to deliver the standard 120v/60Hz AC service to the wall socket, it can change any or all of the infrastructure that it takes to deliver that service. The source of power can be switched from a coal-burning plant to a wind farm. The wires on the street can be changed from above ground to underground. The systems that monitor the electric grid can be upgraded. The trucks that service the grid can be replaced. As long the electric company delivers power to electricity-consuming devices based on the standard, the utility can make whatever business decisions it wants in order to serve power in an efficient, environmentally friendly and cost-effective way.

Likewise, because an API endpoint sufficiently decouples the consuming application from the infrastructure that provides a service, the service provider is afforded tremendous flexibility when it comes to how it offers its service. For example, if the infrastructure behind the API involves physical servers at a data center, the service provider can switch to virtual servers that run in the cloud from companies like Amazon or Rackspace. 

If the software running on those servers (such as credit card processing software) is written in, say, Java running on an Oracle-based Java application server, the service provider can migrate that code-base to Node.js (server-side Javascript) running on Windows Azure. As long as the specification for what the service provider is delivering to the endpoint remains unchanged, the changes to the infrastructure behind the endpoint should go unnoticed by the applications that rely on that API.  

Like a legal contract between two parties, this agreement between what the consuming application expects to see at the endpoint and what the API provider is providing at the endpoint is often called the “API contract.” If an infrastructural change by the API provider results in a material change to the API’s endpoint, the contract is essentially breached and the consuming applications that depend on that API will likely break unless the API provider gives developers fair warning of the impending change. Going back to the electricity metaphor, if the electric company changes something about your electrical service’s specification--for example, it changes the rate at which the current alternates directions from 60Hz to 50Hz--it could imperil your devices. 

This is part of our series What Are APIs and How Do They Work? In part 5, we take a look at the ways in which Web technology is an important enabler of networkable APIs, thus giving rise to the idea of “Web APIs.”