This is the second part of our series What Are APIs and How Do They Work? In part 1, we used the standard electrical socket found in most walls as a metaphor for explaining the principles of an API.
Imagine what life might be like without such a standard. For example, with no plug, matching socket or standard particulars (often called specifications), we might have to hard-wire appliances into the walls of buildings. This would involve gathering the required tools, unsheathing all the wires and splicing the wires together. Of course, we would also need to know something about the wires coming out of the wall. Moving an appliance from one location to another would be a major undertaking in disconnection and reconnection.
Luckily, we don’t have to do any of this. We have plugs and sockets that conform to a standard, which affords the following “conveniences”:
- Through the standard interface, any compatible consumer (in this case, a device) can easily outsource its electrical requirements to the service, and the device can expect to get the same results. Knowing that electricity can be outsourced through a predictably available standard interface, device manufacturers can focus on making great devices and not on figuring out how those devices are going to get their power (other than supporting the standard interface).
- Consuming-devices are easily moved from one socket to another. Thanks to a standard interface, moving a hair dryer from a home in Boston to a hotel in San Francisco is no different than moving it from your bedroom to your kitchen. And even if the pattern of the standard interface changes—as it does when traveling from North America to the United Kingdom--consuming devices can be easily adapted.
- The electrical socket interface is a layer of abstraction (it hides the specifics) to the underlying service. The consumer (again, not a person but rather a device) is blind to things like the color of the wiring in the walls, other devices the wiring is shared with, how the electricity is generated (whether it be from a wind farm, nuclear plant, coal-fired generator or solar array) or where those sources of power are located. For whatever motivations (such as cost savings, policy or public pressure), so long as the service delivers 120 volts of 60Hz AC power to the wall socket in a way that conforms to the standard, the service provider is free to change anything and everything from just behind the socket all the way to the source of power. Any such changes are transparent to consuming devices.
- The same transparency works both ways. To the service, all consumers look the same. It is essentially blind to the specifics of the consuming device that’s on the other side of the electrical socket.
As interfaces go, APIs and the benefits they provide to their consumers (such as desktop, Web, mobile and server-side applications) are not that much different from electrical sockets and the benefits they provide to their consumers (such as computers and appliances).
For example, in much the same way a consuming device can outsource its electricity to a service through a wall socket interface, a consuming application can outsource its requirements for data (such as a patient record) or functionality (such as a location represented as a pin on an interactive map) to a service through an application programming interface. Though the consuming application and service (known as an API provider) are sufficiently decoupled to the point that they know little or nothing about one another, the interface through which they communicate represents a set of agreed-upon standards (similar to the 120v/60Hz AC standard for electricity) that enables applications to make requests of the service and get data and/or functionality in return. From one API to the next, this set of agreed-upon standards is known as the API's "contract."
And, similar to the way in which consuming devices outsource their power requirements to service providers through an electrical network, applications can outsource their requirements for data and functionality to service providers that are across digital networks, like the Internet (or even just across a local-area network at a business). For example, a mobile application for home buyers can incorporate interactive maps and navigation into its user experience by outsourcing that functionality to Google Maps. Each time that mobile application displays a new interactive map, it does so by sending a request across the Internet to a special API that’s offered by Google for that very purpose.
So, as with electricity, APIs can be consumed (to the extent that an application outsources certain requirements to an API) and provided as a service.
In addition to calling APIs from across a network, application developers can leverage APIs offered by the local system or device that their application runs on. For example, applications can discover a smartphone’s current location by calling the API associated with the phone’s GPS receiver. There’s also an emerging class of APIs offered by modern Web browsers, such as Chrome and Firefox, that are like the aforementioned standard electrical sockets--across all types of systems (desktops, tablets, smartphones, and so on), these browsers offer a standard way for browser-based applications to access the host device’s storage, audio system, cameras, and much more. From across a network, the source of data or functionality that’s called through an API could be an application server (a database server, for example), a translation service or even a network-enabled refrigerator.
This is part of our series What Are APIs and How Do They Work? In part 3, we’ll discuss the types of APIs that make the Web programmable (as in the “ProgrammableWeb”).