Make APIs for You and Me

Learning Objectives

After completing this unit, you’ll be able to:

  • Define and describe an API.
  • Name common uses of APIs.
Note

Note

This module was produced in collaboration with ProgrammableWeb.

Technology has become a part of every aspect of our lives. We are all connected in some way.

  • Through our phones when we look up Yelp reviews for nearby restaurants.
  • Through travel booking sites with access to all available flights and hotels.
  • Even home appliances are able to replenish supplies; for example, ordering microwaveable popcorn directly from an Alexa-enabled AmazonBasics microwave oven.

Have you ever wondered how this works?

For decades, most computer software have been created and distributed with one type of user in mind: a human. No matter what chain of events took place under the hood of that software, a human user was traditionally at the end of that chain. Because of this, the user was only able to access data through a user interface (UI).

But what if that same data could just as easily be accessed by another piece of software? In this case, the UI concerns are very different. After all, software doesn’t have eyes, emotions, or intuition—it doesn’t need an over-the-top graphical user interface. However, in the same way a UI is tailored to humans, software needs an interface that makes it easy to get data or functionality from other software.

Say, hello to application programming interfaces, otherwise known as APIs. 

What Is an API?

An API is equivalent to a user interface, except it’s designed for software instead of humans. This is why APIs are often described in the media as technology that allows applications to talk to one another. 

Image of a desktop monitor with the sub-text Client. An arrow points to a server to send a request. Another arrow points back to the desktop monitor with the return response

In a nutshell, the client sends a request for specific information or functionality to another system. That system returns the data or functionality in a response. To send or receive data, there is an expectation that it will be in a specific format that both sides can understand. Makes sense? Let's take a closer look.

A business owner at a local fitness club wants to plug in her new gym equipment for the club’s new location. She knows that since she lives in North America, she needs a US household plug to do this. She also knows wall sockets deliver 120 volts of electricity. These known guidelines essentially set an expectation for any device needing to be plugged into the wall. 

API works in a similar way.

APIs: The Electric Current Between Software

So what, if anything, do electric wall sockets have to do with APIs? 

Image of a desktop, a refrigerator, and a cell phone all connected to an API gear icon.

Think of it like this: 

  • The electricity coming from the wall is a service. It can stop and start at any time.
  • The treadmill plugged into the wall uses the electricity to run.
  • Since the treadmill does not have its own source of power, the treadmill is outsourcing the power it needs from the service provider, for example windmills or solar power.

While electrical sockets differ depending on where you are in the world, they have predictable patterns of openings; and electrical plugs fit those patterns. 

All these specifications essentially set expectations on behalf of any device that wants to use the service. The plugs and power supplies conform to the patterns and specifications (like 120 volts) for the service. The same goes for APIs. 

Like standardized electrical outlets, APIs offer similar standard patterns that make it easy for other software to exchange data and functionality. Any software that needs to send or receive data must adhere to those specifications to make a request. 

retargeting