The literal definition of “API” is Application Programming Interface — a way for one computer application to interact with another computer application (i.e., using code). An API exists in contrast to, say, a GUI (Graphical User Interface), by which interaction with an application is achieved using a visual representation of its functions, designed for use by a human being (i.e., not using code).
APIs can be public or private, and some APIs are designed only for use by specific applications in very specific ways. Other APIs may be designed for extremely broad usage by effectively any application (for example, an API that retrieves the current time and date). APIs are as diverse as the software they interface with. And while a particular programming language does not define APIs, there are API implementations that rely on specific protocols (like HTTP) and architectures (such as REST) that have become dominant in the internet and mobile device era.
Esper APIs
Why Do We Use APIs?
In practice, APIs exist to enable interoperability and the sharing of data, allowing software created by various developers to interact in meaningful ways that enable new capabilities and allow the sending of specific information between computers. APIs also tend to be a secure way to do these things, as the information shared between any two applications is generally kept at the bare minimum to enable the desired function. The computers (i.e., a smartphone and server) using an API are never fully exposed to one another, only to the data transferred over the API. (Though, of course, badly designed and exploitable APIs do exist.)
Modernly, many APIs use internet protocols (HTTP) to communicate, and most are designed on a common architecture known as REST, allowing developers to easily work with many APIs from many applications with commonly understood principles and functions. This is all pretty high-concept, though — so what does “using an API” actually look like?
Examples of API use cases
Many of the mobile apps on your smartphone rely on APIs for basic functionality, and the ways they do so are incredibly varied. Here are just some of the ways APIs are used on your smartphone.
- Display current weather conditions (using a weather data API)
- Show the live status of an order in a food delivery app (using location and order data APIs)
- Display the status of your upcoming flight and notifying you of delays (using the airline’s status API)
- Pay with Apple Pay and Google Pay in other applications (using a payment provider API)
- Display information in a notification (using an operating system’s notification API)
- In-app camera capture for social media (using your phone’s camera API)
- Copy and paste text or other content to and from the clipboard (using the operating system’s clipboard API)
- Display the track information, album art, and playback position of a song on the lockscreen (using the OS’s media control API)
- Control and see the status of a smart light bulb or thermostat from an app (using a smart home / IoT API)
These are just a few examples — the number of APIs you unknowingly interact with every day is much, much longer than this list. Many APIs aren’t exposed in ways that are visible to you, the end user of an application or device. But if they weren’t there, many things you take for granted, like receiving notifications or estimating your time of arrival when using turn-by-turn navigation, wouldn’t work!
How Do APIs Work?
In principle, APIs don’t “work” in any specific way; they’re just a concept. But in reality, there are two fundamental types of APIs you most commonly interact with: OS (or platform) APIs and internet-enabled APIs. Understanding the purpose of each can give some insight into the way APIs work in practice.
OS APIs (also called platform APIs) exist in the context of an operating system and applications running on that operating system. In order for most applications to be meaningfully useful (whether on a laptop, smartphone, or smartwatch), they must interface with functions of the operating system — as described in some of our API use cases above.
A music streaming app will need to interface with the media playback API, at a minimum, to function! A clock app needs to use the system time API, and so on, and so forth. These APIs are specific to each operating system, and developers must build their applications respective of the APIs for each OS they want an application to run on. The developers of those operating systems will publish the API documentation necessary for a developer to do this. This is one reason, among many, that you can’t simply build a “unified” app that works across Windows, Android, and iOS — these OSes all speak different API “languages” that the app must conform to in order to function. (This, conversely, is one of the motivations behind webapps, which use web APIs that are compatible across most operating systems.)
REST APIs
Internet-enabled APIs, the kind most commonly referred to when discussing APIs today, work by sending data between two applications using an internet protocol, typically HTTP. Without getting too technical, most developers have broadly settled on designing internet-enabled APIs with the REST architecture, which is what is meant when you see someone refer to a “RESTful API.”
REST stands for REpresentational State Transfer, which entails a set of technical design principles by which an API is built. Without getting too deep into what those principles are (it’s pretty complex stuff), the basic idea is that RESTful APIs can be built with almost any programming language, support a very large variety of data types, and are lightweight (low-compute, low-data, low-bandwidth) and secure by design. By adhering to RESTful principles, the developer of an API can ensure that other developers can quickly understand and build functionality in their own apps using that API. Again, REST APIs are not a programming language, and there is no standards body governing “REST compatibility.” But if you actually want other developers to use and trust your API, adhering to RESTful principles is by far the best way to do so, and so the standard tends to be self-enforcing.
How are APIs Used in Enterprise Applications?
APIs have a wide variety of uses in enterprise; everything from facility access control, to smart HVAC and lighting systems, to enabling custom applications on employee smartphones or dedicated usage devices like kiosks. A restaurant using a self-ordering kiosk that runs an application will rely on APIs to display information like menu pricing and item availability, and also for functions like processing payments and applying loyalty discounts. Using properly-designed RESTful APIs in such applications will also ensure customer and ordering information is only shared in the ways specifically enumerated in those APIs, and that the information is transferred using secure internet protocols like TLS.