An API, which stands for application programming interface, is a set of protocols that enable different software components to communicate and transfer data. Developers use APIs to bridge the gaps between small, discrete chunks of code in order to create appications that are powerful, resilient, secure, and able to meet user needs. Even though you can't see them, APIs are everywhere-working continuously in the background to power the digital experiences that are essential to our modern lives.
Here, we'll give a high-level overview of the history of APIs and hwo they work before reviewing the different types of APIs and how they are used. We'll also discuss some common benefits and use cases for APIs-and offer a few real-world API examples that can help you get started.
In order to fully understand the role that APIs play in our lives, it's important to understand how they have evolved. APIs have been around for decades, with modern web APIs first taking shape in the early 2000s. The history of APIs since that period can be roughly broken down into the following five phases:
In the early 2000s, web APIs emerged as a new method for emerging startups to not only make products and services available online, but to also enable partners and third-party resellers to extend the reach of their platforms. This era of APIs was defined by Salesforce, eBay, and Amazon, and these companies continue to dominate the API playing field today.
A shift in the API landscape occurred in the mid-2000s, as a new group of companies—such as Flickr, Facebook, and Twitter—realized that APIs could change the way we share information with one another. While these APIs weren't as intrinsically linked to revenue as their commercial predecessors, they nevertheless provided significant value to their organizations. For instance, Facebook launched version 1.0 of its API in August of 2006, which allowed developers to access Facebook users' friends, photos, events, and profile information. This API played a crucial role in establishing Facebook as one of the most popular social networks in the world.
In 2006, Amazon introduced Amazon Simple Storage (S3), which marked yet another turning point in the history of APIs. S3 is a basic storage service in which resources are accessible via API and CLI, and its pay-as-you-go model provides a cost-efficient way for organizations to monetize digital assets in the online economy. Just six months later, Amazon released Amazon Elastic Compute (EC2), which enabled developers to use web APIs to deploy infrastructure that would power the next generation of applications. Both S3 and EC2 continue to play an essential role in application development today.
The world was introduced to Apple's iPhone and Google's Android in 2007. The ability to carry the web in our pockets radically changed how we live—and spurred a massive investment in mobile applications that are powered by APIs.
For instance, Twilio launched its API-as-a-product platform in 2007, which allowed developers to make and receive phone calls from any cloud application. Instagram then launched its photo-sharing iPhone application in October 2010, and it had one million users just three months later. Instagram did not initially provide an API, but it began work on one in early 2011 in response to user demand. These API-first companies played an essential role in creating the blueprint for how APIs are delivered today.
Phase 5: APIs for connected devices
Around 2010, some developers began using APIs to connect everyday objects—such as cameras, thermostats, speakers, microphones, and sensors—to the cloud. This next generation of devices, which includes Fitbit, Nest, Alexa, can send and receive data, content, media, and other digital resources, further changing the way we interact with the world around us.
APIs work by sharing data between applications, systems, and devices. This happens through a request and response cycle. The request is sent to the API, which retrieves the data and returns it to the user. Here's a high-level overview of how that process works.
- API client
The API client is responsible for starting the conversation by sending the request to the API server. The request can be triggered in many ways. For instance, a user might initiate an API request by entering a search term or clicking a button. API requests may also be triggered by external events, such as a notification from another application.
- API request
An API request will look and behave differently depending on the type of API, but it will typically include the following components:
- Endpoint: An API endpoint is a dedicated URL that provides access to a specific resource. For instance, the /articles endpoint in a blogging app would include the logic for processing all requests that are related to articles.
- Method: The request's method indicates the type of operation the client would like to perform on a given resource. REST APIs are accessible through standard HTTP methods, which perform common actions like retrieving, creating, updating, and deleting data.
- Parameters: Parameters are the variables that are passed to an API endpoint to provide specific instructions for the API to process. These parameters can be included in the API request as part of the URL, in the query string, or in the request body. For example, the /articles endpoint of a blogging API might accept a “topic” parameter, which it would use to access and return articles on a specific topic.
- Request headers: Request headers are key-value pairs that provide extra details about the request, such as its content type or authentication credentials.
- Request body: The body is the main part of the request, and it includes the actual data that is required to create, update, or delete a resource. For instance, if you were creating a new article in a blogging app, the request body would likely include the article's content, title, and author.
- API server
The API client sends the request to the API server, which is responsible for handling authentication, validating input data, and retrieving or manipulating data.
- API response
Finally, the API server sends a response to the client. The API response typically includes the following components:
- Status code: HTTP status codes are three-digit codes that indicate the outcome of an API request. Some of the most common status codes include 200 OK, which indicates that the server successfully returned the requested data, 201 Created, which indicates the server successfully created a new resource, and 404 Not Found, which indicates that the server could not find the requested resource.
- Response headers: HTTP response headers are very similar to request headers, except they are used to provide additional information about the server's response.
- Response body: The response body includes the actual data or content the client asked for—or an error message if something went wrong.
In order to better understand this process, it can be useful to think of APIs like restaurants. In this metaphor, the customer is like the user, who tells the waiter what she wants. The waiter is like an API client, receiving the customer's order and translating it into easy-to-follow instructions for the kitchen—sometimes using specific codes or abbreviations that the kitchen staff will recognize. The kitchen staff is like the API server because it creates the order according to the customer's specifications and gives it to the waiter, who then delivers it to the customer.
You can also categorize APIs according to their architectural style, of which there are many. The most frequently used architectural styles are:
- REST
As discussed above, REST is the most popular API architecture for transferring data over the internet. In a RESTful context, resources are accessible via endpoints, and operations are performed on those resources with standard HTTP methods such as GET, POST, PUT, and DELETE.
- SOAP
SOAP, which stands for Simple Object Access Protocol, uses XML to transfer highly structured messages between a client and server. SOAP is often used in enterprise environments or legacy systems, and while it includes advanced security features, it can be slower than other API architectures.
- GraphQL
GraphQL is an open source query language that enables clients to interact with a single API endpoint to retrieve the exact data they need, without chaining multiple requests together. This approach reduces the number of round trips between the client and server, which can be useful for applications that may run on slow or unreliable network connections.
- Webhooks
Webhooks are used to implement event-driven architectures, in which requests are automatically sent in response to event-based triggers. For instance, when a specific event occurs in an application, such as a payment being made, the application can send an HTTP request to a pre-configured webhook URL with the relevant event data in the request payload. The system that receives the webhook can then process the event and take the appropriate action.
- gRPC
RPC stands for Remote Procedure Call, and gRPC APIs were originated by Google. In gRPC architectures, a client can call on a server as if it were a local object, which makes it easier for distributed applications and systems to communicate with one another.