The first four parts covered what an API is, how a request and response work, how the answer becomes a page, and how keys and limits fit in. This part puts it all together on one real example: the live weather page on this site. It's worth opening it in another tab, picking a place and scrolling to "Behind the scenes" as you read.
The big picture
There are two separate moments in the life of the page: when I publish it, and when someone visits it.
Two moments: building the page and visiting it
When I publish
The page, its script, the list of places and the code-to-icon table
Eleventy turns it all into HTML, CSS and JavaScript. No weather yet.
Serves the same files to everyone. It doesn't call any API.
Every time someone visits
Loads the page, then its script runs
Sends back today's weather as JSON
Turns the numbers into a temperature, words and an icon
This site is static: the host sends the same files to everyone and runs no code of its own. That keeps it fast and cheap, but it means anything live has to happen in the visitor's browser. The weather is the only live part of the page.
Why there's no key
Open-Meteo is free for non-commercial use and doesn't need a key, so the browser can ask it directly and there's nothing to keep secret. If the page used a paid weather API, the browser couldn't hold the key (Part 4). The design would gain one step: a small server function holding the key in GitHub Secrets, with the browser asking that function instead of the weather API. Choosing an API that needed no key kept this project simple, and that kind of trade-off is a product decision as much as a technical one.
Step by step
Here's everything that happens between choosing a place and seeing its weather, usually in well under a second:
What happens when you pick a place
The page looks up Edinburgh's latitude and longitude in its list of places.
LikeChecking the sticky note on the fridge before ringing someone
If so, it reuses that answer straight away (a cache). Weather doesn't change that fast, and it's polite to the people running the API.
Builds the web address from Part 2 and waits up to 10 seconds for an answer (a timeout).
Draws the weather
Turns the JSON into the page (Part 3): the icon, temperature and five-day forecast, and announces the result to screen readers.
Says so, kindly
"The weather API didn't answer", with a Try again button. The rest of the page carries on working.
?place=edinburgh, so a link to the page opens on the same place.Writing it up as a user story
If the weather page were a ticket on a real team's board, it might read like this. Notice how much of it is about the request, the response and what happens when things go wrong:
As a visitor, I want to see the current weather and a five-day forecast for a place I choose, so that I can see a live API integration working.
- Given I open the page, then I see the current weather for Welwyn Garden City: temperature, conditions, feels like, wind, humidity and an icon.
- Given I choose another place, then the page requests that place's weather and redraws, and the address includes the place so I can share it.
- Given the API answers with a weather code, then the page shows the matching words and icon from the agreed lookup table, with a moon instead of a sun at night.
- Given the API returns an error or doesn't answer within 10 seconds, then I see a friendly message and a Try again button, and nothing else on the page breaks.
- Given I asked for the same place in the last 10 minutes, then the page reuses that answer instead of sending another request.
- Given I use a screen reader, then the new weather is announced when it loads.
Try it
That's the series. If you'd like to see every step for real, the weather page shows the request change as you pick places, the JSON that comes back and the code being turned into an icon.
Once you know what to look for, you'll spot APIs everywhere: the map on a shop's contact page, the delivery tracker on an order, the "Sign in with Google" button. Each one is a product asking another service a question, and someone on the team deciding what the customer sees when the answer comes back, or doesn't.