What is an API

A screen for people, a window for apps

In the last lesson we saw that when a browser sends a request, the server sends back a response. The response a person gets is usually a web page, with text, pictures, and buttons laid out to look nice.
That suits human eyes, but for an app to find a single temperature in it, it would have to pick the whole screen apart. So programs trade data they can use right away instead of screens. The window set up for this is called an API.

Tap the people screen and the app window to compare. Which is easier for an app to use?

The same information can take different shapes. People get a screen dressed up to look nice; apps get data with nothing extra. The screen is made for a person to read, and the window is made for a program to read.
So how does an app talk to that window? In fact, many APIs use the HTTP you just learned: send a request to a set address, get a response back. What the request must contain, though, is fixed in advance by each window.

Asking in a fixed format

You cannot say just anything to a window. You have to ask in the format set in advance, for example by filling in set fields such as "city: Seoul, wanted: today's weather."
It is like ordering at a restaurant by the exact names on the menu. When the order uses the agreed words, the kitchen starts cooking at once without confusion. An API, too, understands only requests in the agreed format, and to a request that does not fit, it answers that something is wrong.

Tap an agreed request to send it to the API. Because the format is fixed, the window understands it at once.

The request is sent, so now it is time for an answer. Instead of a screen meant for a person, what does the API answer with?
The answer comes as neatly arranged data the app can use right away. With no decoration or pictures, only the needed values, it is small too. Let's unfold that data in the next step and see what it looks like.

It answers with data, not a picture

An API's answer is not a picture. It is data in which names are paired with values, for example temperature 23 and sky clear. Each value has a name, so it is clear what the value means.
The most widely used format for writing names paired with values is JSON. It is simple enough for people to read and easy for programs to handle. The app picks out just the values it needs from this data and draws them on its own screen.

Tap the data to unfold it. Not a picture but clean names and values (temperature 23, sunny).

Because every value has a name, the app does not get confused. If it needs the temperature, it takes the temperature; if it needs the sky, it takes the sky. Had the app needed to dig a number out of a screen, a small change in the page's layout could have made it read the wrong value.
And there is not just one such window. Map windows, weather windows, payment windows: the world is full of open APIs. What can you build by using two or more together?

Combining windows into a new service

Each window does just one job. The map window gives locations and maps; the weather window gives the weather.
But combine the two, and a new service appears that shows the weather of each spot right on the map. Like fitting blocks together, you gather several windows to build something bigger. Many of the apps we use every day are built this way, by combining windows from several companies.

Tap the map API and the weather API in turn to combine them. Together they make a new service that shows the weather on the map.

When data from the two windows met, something neither could do alone appeared. Neither the map nor the weather was built from scratch; existing windows were simply borrowed and joined.
That is why new services can be built quickly: instead of reinventing the wheel, you use well-made parts. The side that opened the window needs to know who uses it and how much, so many APIs ask that each request carry a unique string that works like a key.

Summary

In short: people look at screens, but programs trade data, and the agreed window for that is the API.
Ask in a fixed format, and it answers not with a picture but with data made of names and values. Combine several windows, and you have a new service. So instead of building everything from scratch, you can borrow existing windows to make something new.

Tap the key points in order to review. (app window → request in a fixed format → answer in data → combine into a new service)

Now you know how apps trade data with each other. Behind every app you can see, many windows are quietly at work. Next time you open a weather app, it is fun to wonder which window its screen got its data from.
But remember that HTTP does not remember past requests. So how does an online shop recognize you, logged in, on every page? The next lesson covers the answer: sessions and cookies.