API: the window where apps talk to each other
How does a weather app know the weather? It does not look at the sky itself. It asks somewhere else that has the weather. But unlike a person reading a web page, apps trade only clean data in a fixed format. That agreed window is the API.
A screen for people, a window for apps
Earlier we learned that when you send a request,
a response comes back.
The response a person gets is usually a web page.
It has text, pictures, and buttons.
Nice for human eyes,
but too messy for an app to use.
So between apps, instead of a screen,
they trade data they can use right away.
That agreed window 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 look different.
To people it gives a screen dressed up to look nice,
to apps it gives data with no extra fluff.
The screen is made for a person to read,
the window is made for an app to read.
Then how does an app
speak to that window?
Next we see how to make a request.
Request in a fixed format
You cannot just say anything to the window.
You must ask in the format set in advance.
For example, an agreed request like
"tell me Seoul's weather."
It is like reading a menu at a restaurant
and ordering by the set names.
When the order is the agreed wording,
the kitchen makes it at once without confusion.
An API too understands only agreed requests.
Tap an agreed request to send it to the API. Being a fixed format, the window understands at once.
Now that the request is sent,
it is time for an answer.
Instead of a screen sent to a person,
what does the API answer with?
So an app can use it right away,
it answers with neatly arranged data.
What that data looks like
we unfold in the next step.
It answers with data, not a picture
An API's answer is not a picture.
It is data where names are paired with values.
For example temperature is 23,
sky is clear, like that.
The name makes it clear what each value is.
This way of writing names with values
is often called JSON.
The app picks just the values it needs
from this data and uses them on its own screen.
Tap to unfold the data. Not a picture but clean names and values (temperature 23, sunny).
Since each value has a name,
the app does not get confused.
Need the temperature, take the temperature,
need the weather, take the weather.
A picture would have to be figured out,
but data can be used right away.
And there is not just one such window.
A weather window, a map window, many windows exist.
So what if we combine two or more?
Combine windows to make a new service
Each window does just one thing.
The map window tells you the location,
the weather window tells you the weather.
But what if we join the two?
A new service appears that shows
the weather of a spot right on the map.
Like fitting blocks together,
we gather several windows to make something bigger.
The apps we use are made this way.
Tap the map API and the weather API in turn to combine them. Joined, they make a new service that shows weather on the map.
When data from the two windows met,
something neither could do alone appeared.
No need to build a map or weather from scratch,
we just borrowed existing windows and joined them.
So a new service can be made fast.
Instead of carving the wheel again,
we take well-made parts and use them.
This is how the API changed the world.
Let's wrap up
Gathered on one line, it is this.
People look at screens, but apps trade data.
That agreed window is the API.
Request in a fixed format
and it answers with data of names and values, not a picture.
Combine several windows and a new service appears.
So we need not build everything from scratch,
we can borrow existing windows to make new things.
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 one app you can see,
many windows are quietly at work.
Next time you open a weather app,
give it a thought.
From which window
did that screen pull its data,
you might wonder.