How the API Abstraction principle benefits service providers
When the endpoint of an API is architecturally the point where the application consuming API is essentially decoupled from the consumed service, it provides the API provider with a significant amount of flexibility in providing its service.
We’ve been using electricity and electrical outlets as a metaphor for APIs, and the comparison is here, too: as long as the power company continues to supply the standard 220v or 110v as a service to the wall outlet, you can change any or all the infrastructure that is needed to deliver that service. The power source can be changed from a coal plant to a wind farm. Cables in the street can be switched from top to ground. Systems that monitor the power grid can be upgraded. Trucks serving the grid can be replaced. As long as the electric company supplies power to electricity consuming devices based on the standard, the company can make the business decisions it wants to be able to serve in an efficient, environmentally friendly and cost-effective way.
Similarly, because an API endpoint sufficiently decouples the consuming application from the infrastructure that provides a service, the service provider has tremendous flexibility when it comes to how it offers its service. For example, if the infrastructure behind the API involves physical servers in a data center, the service provider can switch to virtual servers running in the cloud from companies like Amazon or Rackspace.
If the software running on such servers (such as credit card processing software) is written in Java, for example on an Oracle-based Java application server, the service provider can migrate that code base to Node .js) in Windows Azure. As long as the specifications of what the service provider is delivering to the endpoint remain unchanged, changes to the infrastructure behind the endpoint should go unnoticed by 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 provides at the endpoint is often called an “API contract.” A material change to the API endpoint, the contract is essentially breached and consuming applications that rely on that API will likely be broken unless the API provider gives developers fair warning of the impending change.
Going back to the electricity metaphor, if the power company changes anything about the specification of its electrical service – for example, it changes the speed at which alternating current addresses from 60Hz to 50Hz – it could jeopardize your devices.
Editorial: Diego San Esteban
