Today people all over the world consume data across a variety of networks, geographies, and devices. Web applications are used every day for shopping, ordering food, checking the weather, reading the news, or interacting with friends and family.
How do these applications enable users to consume data from these different applications, across thousands of different devices all around the world? How does data get from point A to point B?
The answer to this question in most cases is: “through an API.” So, what is an API?
What is an API?
An API, or application programming interface, is the unsung hero of the modern web. From a technical perspective, it is a set of programming instructions and standards for accessing a web-based software application or service. APIs are constructed by web service providers and give directions on how to interact with that service. An API typically describes the service’s available functionality, how it can be used and accessed, and what formats it will accept as an input or output.
To explain an API in a more approachable way, think of an API as a waiter at a restaurant:
At a restaurant, you, as the customer, have a menu of items that you can order with specific instructions as to how you want those items prepared.
You give your order to the waiter, “I want the filet mignon, medium-rare, with a side of creamed spinach and a fully-loaded baked potato with no chives.”
The waiter then writes down your order and delivers it to the kitchen who prepares your meal to your exact specifications (hopefully). Once the meal is prepared, the waiter picks up your food from the kitchen and serves it to you at your table.
The waiter’s role in this scenario closely mirrors the role of an API in the delivery of data on the modern web. Like a waiter, the API takes a set of instructions (a request) from a source (could be an application or engineer), takes that request to the database, fetches the requested data or facilitates a set of actions, and returns a response to the source.
Consumer-Facing APIs in Action
One of our customers, The Weather Company, collects weather data from millions of endpoints around the globe. This data is stored in their databases and is accessed by consumer-facing applications via hundreds of different APIs. It is likely that your phone interacts with one of these APIs multiple times a day.
As an Android user, I have a widget on my home screen that always lists the current temperature and weather conditions for my current location. To display that information, my phone sends a request at a specified interval to The Weather Company’s API. The request asks for specific information, such as the temperature for the time and place that I am in. The API then interprets that request, fetches the appropriate information and delivers a response to my phone with that information. This is just one of the many different ways that data is requested via an API.
At Rigor, we capture and report on a variety of performance metrics for digital businesses and provide suggestions for improving site performance.
Our optimization product, Zoompf, offers a variety of out-of-the-box reports and visualizations that our users can access through our online platform. However, while we have done a good job of forecasting how many of our customers want to consume performance data, many teams have unique internal processes and KPIs that influence how they choose to access and view our data.
For teams that wish to slice and dice our data in different ways, or who choose to integrate our platform into their internal processes, we built an API to enable them to do this.
In a recent blog post, our head of Engineering, Kyle Conarro, discussed how we integrated our own API into our product releases to identify performance regressions introduced with a new deployment.
We wanted to identify if and when “the thing we just built makes our product slower.” To accomplish this feat, we built a request into our deployment process to the Zoompf API that:
- triggers a performance scan on our staging environment
- posts a link to the results from the scan in our internal messaging system, Slack.
An API, or application programming interface, is the gateway for interacting with modern web applications. APIs serve the following functions:
- Provide documentation on how to programmatically interact with a web application
- Act as intermediaries between two web applications or an application and a developer.
- Execute a series of predefined functions for interacting with an application. Common functions include:
- Fetching data
- Posting data
- Executing tasks
Look out for another post next week where we’ll be discussing the different types of APIs being used and how they differ from each other.