Working with web data

Make a day22 folder for today’s files, create and activate a virtual environment in it (Day 13: python -m venv .venv, then activate it), and open the folder in your editor. In 22.2 you will install the requests package into that environment. Programs that call a web API need an internet connection; the programs that read a saved response from a file do not.

Every program so far has worked with data you typed, wrote into the code, or kept in a file. Much of the data people care about lives on other computers and changes all the time: today’s weather, train times, exchange rates, the scores of a game in progress. Today your programs learn to ask another computer for data, over the internet, and to cope calmly when the answer is slow, wrong, or never comes.

All of today’s live examples use Open-Meteo (open-meteo.com), a free weather service that needs no account and no key for non-commercial use. Its answers change every hour, so output from a live call is marked sample output: yours will show different numbers. Output from a program that reads a saved answer from a file is exact.

When you open a web page, your browser sends a short message to another computer asking for the page, and that computer sends the page back. A Python program can send the same kind of message. Before writing one, you need a picture of what travels in each direction.

The computer that asks is the client: your browser, or your Python program. The computer that answers is the server. They talk using HTTP (Hypertext Transfer Protocol), the set of rules every website and web service follows. The conversation always has two halves:

• The client sends a request: a message that says what it wants.
• The server sends back a response: a message with the answer, or with a reason it cannot give one.

It works like asking at a library desk: you hand over a slip naming what you want, and the librarian hands back the book, or a note saying it is missing. Where the analogy stops: the server remembers nothing about you between requests, so every request must carry everything the server needs to know.

What you want is named by a URL (Uniform Resource Locator), a web address. Here is one that asks Open-Meteo for the temperature in London right now:

https://api.open-meteo.com/v1/forecast?latitude=51.51&longitude=-0.13&current=temperature_2m

A request also has a method, the verb that says what to do. GET means “send me this”, and it is the only method you need today. (Others, such as POST, send data to the server, the way a form does.)

The response has three parts:

Here is that exchange, shortened (real messages carry more headers). The request:

GET /v1/forecast?latitude=51.51&longitude=-0.13&current=temperature_2m HTTP/1.1
Host: api.open-meteo.com

The response (sample output):

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"latitude":51.51147,"longitude":-0.13078308,"generationtime_ms":4.958868026733398,"utc_offset_seconds":0,"timezone":"GMT","timezone_abbreviation":"GMT","elevation":29.0,"current_units":{"time":"iso8601","interval":"seconds","temperature_2m":"°C"},"current":{"time":"2026-10-15T18:30","interval":900,"temperature_2m":18.4}}

The body is JSON (Day 14), all on one line, because it is written for programs, not people. A URL that answers with data for programs instead of a page for people is part of a web API (Application Programming Interface): a service that other programs can call. Paste the URL into your browser’s address bar and you will see this same JSON; the browser sends a GET request for you.

https://geocoding-api.open-meteo.com/v1/search?name=Paris&count=2

Python’s standard library can send HTTP requests (with a module called urllib.request), but it takes several steps for each one. Nearly every Python programmer uses the third-party package requests instead, which turns a request into one function call. Day 13 used it as the first example of installing a package. With your day22 environment active:

python -m pip install requests

requests.get(url, timeout=10) sends a GET request to url, waits for the response, and returns a response object that holds everything the server sent back. (timeout=10 means “give up after 10 seconds without an answer”. 22.7 explains it; always include it.)

import requests

url = (
    "https://api.open-meteo.com/v1/forecast"
    + "?latitude=51.51&longitude=-0.13&current=temperature_2m"
)
response = requests.get(url, timeout=10)
print(response.status_code)
print(response.headers["Content-Type"])
print(response.text[:60])
data = response.json()
print(data["current"]["temperature_2m"])

Sample output:

200
application/json; charset=utf-8
{"latitude":51.51147,"longitude":-0.13078308,"generationtime
18.4

The URL is long, so it is built from two strings inside parentheses (Day 19’s line continuation). Each print shows a different part of the response object:

response.text[:60] slices the first 60 characters of the body (Day 3), which shows that text is just a string. response.json() does the useful work: it reads that string as JSON and gives back a dictionary, so data["current"]["temperature_2m"] reaches into it the way you reached into nested dictionaries on Day 8. 22.5 looks at that in detail.

A response always comes back, even when something went wrong. The URL might name a service that does not exist, a value in the query string might be impossible, or the server might be broken. The status code at the top of every response says which. Its first digit gives the kind of answer:

Each code also has a short name, its reason phrase. These are the ones you will meet most:

You met a few of these in Day 21’s web server log. A program decides what to do with a response by its code, so it helps to write that decision as a plain function:

def status_meaning(code: int) -> str:
    """Return what a status code's range says about a response."""
    if 200 <= code <= 299:
        return "success"
    if 300 <= code <= 399:
        return "redirect: the data is somewhere else"
    if 400 <= code <= 499:
        return "client error: something is wrong with the request"
    if 500 <= code <= 599:
        return "server error: the server failed"
    return "not a status code"


for code in [200, 301, 404, 429, 503]:
    print(code, status_meaning(code))

200 success
301 redirect: the data is somewhere else
404 client error: something is wrong with the request
429 client error: something is wrong with the request
503 server error: the server failed

Each if uses a chained comparison (Day 4) to test one range, and returns as soon as one matches. 429 is a client error even though the request itself was fine: the client did something wrong by calling too often.

An error response usually still has a body, which often explains the problem. Ask Open-Meteo for a latitude of 951.51 (latitudes only go from -90 to 90) and it answers with status 400 and this body (sample output):

{"reason":"Latitude must be in range of -90 to 90°. Given: 951.51.","error":true}

That is not a forecast at all. A program that assumes every response is the data it asked for will go wrong on this one, which is why the next section matters. (response.ok is a shortcut that is True when the code is below 400.)

def next_step(code: int) -> str:
    """Say what a program should do after a response with this code."""
    if code == 200:
        return "use the data"
    if code == 429:
        return "wait, then try again"
    if code in (401, 403):
        return "check the API key"
    if code >= 500:
        return "try again later"
    return "fix the request"


for code in [403, 200, 404, 502, 429]:
    print(code, next_step(code))

403 check the API key
200 use the data
404 fix the request
502 try again later
429 wait, then try again

Here is a surprise: requests.get does not raise an exception for a 404 or a 500. As far as requests is concerned, the server answered, so it hands you the response and lets you decide. If your program carries straight on to response.json() and data["current"], the failure shows up later, as a KeyError about a missing "current" key, far from its real cause.

The fix is one line. response.raise_for_status() does nothing if the code is a success, and raises requests.exceptions.HTTPError if the code is from 400 to 599. Here is what it does, written by hand with Day 15’s tools so you can run it without a network:

class HTTPError(Exception):
    pass


def raise_for_status(code: int, url: str) -> None:
    """Raise HTTPError for a 4xx or 5xx code, as requests does."""
    if 400 <= code <= 499:
        raise HTTPError(f"{code} Client Error for url: {url}")
    if 500 <= code <= 599:
        raise HTTPError(f"{code} Server Error for url: {url}")


raise_for_status(200, "https://api.open-meteo.com/v1/forecast")
print("200 passed the check")
raise_for_status(404, "https://api.open-meteo.com/v1/forcast")
print("This line never runs")

200 passed the check
Traceback (most recent call last):
  ...
HTTPError: 404 Client Error for url: https://api.open-meteo.com/v1/forcast

The first call returns None without raising, so line 14 prints. The second URL misspells forecast, the server would answer 404, and line 8 raises. Line 16 never runs. The real method works the same way, and its message also includes the reason phrase (sample output):

requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://api.open-meteo.com/v1/forcast

So the pattern for every request is three lines, in this order:

response = requests.get(url, timeout=10)
response.raise_for_status()
data = response.json()

Now a bad response stops the program at the line that checks it, with a message naming the code and the URL, instead of producing a confusing error three lines later. 22.7 shows how to catch the HTTPError instead of crashing.

response = requests.get(
    "https://api.open-meteo.com/v1/forcast?latitude=51.51&longitude=-0.13",
    timeout=10,
)
data = response.json()
print("Got a response")
print(data["current"])

response.json() is not magic. It does exactly what json.loads(response.text) does (Day 14): it reads JSON text and builds the matching dictionaries, lists, strings, numbers, bools, and None. You can watch it happen without a network:

>>> import json
>>> body = '{"latitude": 51.5, "current": {"temperature_2m": 18.4}}'
>>> data = json.loads(body)
>>> type(data)
<class 'dict'>
>>> data["current"]
{'temperature_2m': 18.4}
>>> data["current"]["temperature_2m"]
18.4
>>> json.loads("<html>Service Unavailable</html>")
Traceback (most recent call last):
  ...
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Each level of {...} becomes a dictionary, so data["current"] is itself a dictionary, and a second pair of brackets reaches inside it. The last line shows what happens when the body is not JSON at all, such as the error page a broken server sometimes sends: a JSONDecodeError saying the first character was not the start of a JSON value. With requests, response.json() raises its own version, requests.exceptions.JSONDecodeError. (raise_for_status() before json() catches most of these, because error pages usually come with error codes.)

Saving a response to work with offline

Because a body is only text, you can save it in a file once and then work on your code all day without calling the API again. That is faster, does not use up the service’s goodwill, and gives the same answer every run. The file forecast.json holds a response to this request (the extra query parameters ask for three days of highs, lows, and rain; 22.6 explains them):

https://api.open-meteo.com/v1/forecast?latitude=51.51&longitude=-0.13&current=temperature_2m,wind_speed_10m&daily=temperature_2m_max,temperature_2m_min,precipitation_sum&timezone=Europe/London&forecast_days=3

Here is part of the file, saved with indent=2 so a person can read it:

{
  "latitude": 51.51147,
  "longitude": -0.13078308,
  ...
  "current_units": {
    "time": "iso8601",
    "interval": "seconds",
    "temperature_2m": "°C",
    "wind_speed_10m": "km/h"
  },
  "current": {
    "time": "2026-10-15T19:30",
    "interval": 900,
    "temperature_2m": 18.4,
    "wind_speed_10m": 12.2
  },
  ...
  "daily": {
    "time": ["2026-10-15", "2026-10-16", "2026-10-17"],
    "temperature_2m_max": [20.9, 17.2, 13.5],
    "temperature_2m_min": [14.6, 10.0, 8.3],
    "precipitation_sum": [0.0, 8.7, 0.0]
  }
}

import json
from pathlib import Path

# The text a web API sent back, saved earlier in a file.
text = Path("forecast.json").read_text(encoding="utf-8")
data = json.loads(text)

current = data["current"]
units = data["current_units"]
print("Time:", current["time"])
print("Temperature:", current["temperature_2m"], units["temperature_2m"])
print("Wind:", current["wind_speed_10m"], units["wind_speed_10m"])

Time: 2026-10-15T19:30
Temperature: 18.4 °C
Wind: 12.2 km/h

The "daily" block has a different shape: a dictionary of lists, where position 0 in every list belongs to the first day, position 1 to the second, and so on. Lists that line up like that are walked together with zip (Day 11):

import json
from pathlib import Path

data = json.loads(Path("forecast.json").read_text(encoding="utf-8"))
daily = data["daily"]

print(len(daily["time"]), "days")
for date, high, rain in zip(
    daily["time"], daily["temperature_2m_max"], daily["precipitation_sum"]
):
    print(f"{date}: high {high:.1f}, rain {rain:.1f} mm")

3 days
2026-10-15: high 20.9, rain 0.0 mm
2026-10-16: high 17.2, rain 8.7 mm
2026-10-17: high 13.5, rain 0.0 mm

The other common shape is a list of dictionaries, one per record (Day 8). Open-Meteo’s place-name search answers that way. places.json holds a shortened response to https://geocoding-api.open-meteo.com/v1/search?name=Paris&count=2, which asks for at most two places called Paris:

import json
from pathlib import Path

data = json.loads(Path("places.json").read_text(encoding="utf-8"))

print(len(data["results"]), "places")
for place in data["results"]:
    print(f"{place['name']}, {place['admin1']}, {place['country']}")
    print(f"  at {place['latitude']}, {place['longitude']}")

2 places
Paris, Île-de-France Region, France
  at 48.85341, 2.3488
Paris, Texas, United States
  at 33.66094, -95.55551

data["results"] is a list, so len counts the places and the for loop visits each dictionary in it. The f-strings use single quotes for the keys because the whole string is in double quotes.

To read a response you have not seen before, work from the outside in, as with a nested type hint (Day 19): print data.keys() to see the top level, then print one value to see what is inside it. And when a function receives parsed JSON, the honest hint for it is dict[str, Any]. Any, imported with from typing import Any, means “a value of any type”, which is true of JSON values: one key holds a float, another a list.

import json
from pathlib import Path

data = json.loads(Path("no_places.json").read_text(encoding="utf-8"))

for place in data["results"]:
    print(place["name"])
print("Done")

Traceback (most recent call last):
  ...
KeyError: 'results'

import json
from pathlib import Path

data = json.loads(Path("no_places.json").read_text(encoding="utf-8"))

places = data.get("results", [])
if not places:
    print("No places found")
for place in places:
    print(place["name"])
print("Done")

No places found
Done

import json
from pathlib import Path

data = json.loads(Path("places.json").read_text(encoding="utf-8"))

second = data["results"][1]
print(second["country_code"])
print(data["results"][0]["population"] > second["population"])
print([place["timezone"] for place in data["results"]])
print(data.get("total", 0))

US
True
['Europe/Paris', 'America/Chicago']
0

Most APIs take extra details: which place, which measurements, how many results. They go in the query string, after the ?, as query parameters: name=value pairs joined with &. In ?latitude=51.51&longitude=-0.13, there are two parameters, latitude with the value 51.51 and longitude with -0.13. Open-Meteo’s documentation lists the ones it understands; here are the ones today uses:

Writing these by hand gets awkward fast, and some characters cannot appear in a URL as they are: a space would end the URL, and an & inside a value would look like the start of the next parameter. So they are replaced by codes, a process called URL encoding: a space becomes + (or %20), and & becomes %26. The standard library’s urllib.parse.urlencode shows what that looks like:

>>> from urllib.parse import urlencode
>>> urlencode({"latitude": 51.51, "longitude": -0.13})
'latitude=51.51&longitude=-0.13'
>>> urlencode({"name": "New York", "count": 1})
'name=New+York&count=1'
>>> urlencode({"name": "Fish & Chips"})
'name=Fish+%26+Chips'

Numbers are turned into text, pairs are joined with &, and the space and & inside values are encoded so they cannot be mistaken for anything else.

With requests, you never build the query string yourself. Pass a dictionary as params=, and requests encodes it and adds it to the URL:

import requests

params = {
    "latitude": 51.51,
    "longitude": -0.13,
    "current": "temperature_2m,wind_speed_10m",
}
response = requests.get(
    "https://api.open-meteo.com/v1/forecast", params=params, timeout=10
)
response.raise_for_status()
print(response.url)
print(response.json()["current"])

Sample output:

https://api.open-meteo.com/v1/forecast?latitude=51.51&longitude=-0.13&current=temperature_2m%2Cwind_speed_10m
{'time': '2026-10-15T18:30', 'interval': 900, 'temperature_2m': 18.4, 'wind_speed_10m': 12.2}

response.url shows the URL requests really sent. The commas were encoded as %2C, which the server decodes back into commas. The base URL now has no ? at all, and the details live in a dictionary that is easy to read and to change: asking for Paris instead means changing two numbers, not editing a long string.

url = f"https://api.example.com/v1/recipes?q={search}&page=1"

Reading a file on your own computer almost always works. A request crosses the internet, and many things can go wrong that have nothing to do with your code: the Wi-Fi drops, the server is down, the server is so busy it never answers, or a train goes into a tunnel. A program that talks to the network has to expect failure as a normal event, not a rare one.

Timeouts

Without a limit, requests may wait for a silent server for a very long time, and your program sits there looking frozen. The timeout is the longest, in seconds, that requests will wait: timeout=10 means “if the server takes more than 10 seconds to connect, or more than 10 seconds to send the next part of its answer, give up”. Giving up raises an exception you can handle. It does not limit the total time of a long download that keeps arriving, only each wait. Five or ten seconds suits most APIs. The requests documentation recommends a timeout on nearly every request in real code, and so does this course: every request on this page has one.

The exceptions requests raises

When a request fails, requests raises one of its own exception types, all in requests.exceptions:

They form a family: every one of them is a child class of RequestException (Day 17). So except requests.exceptions.RequestException: catches any failure from requests, and an except clause for a child catches only that kind. (requests.exceptions.ConnectionError is a different class from Python’s built-in ConnectionError, so write the full name.)

from typing import Any

import requests


def get_json(url: str, params: dict[str, Any]) -> dict[str, Any] | None:
    """Return the JSON body of a GET request, or None if it failed."""
    try:
        response = requests.get(url, params=params, timeout=10)
        response.raise_for_status()
        return response.json()
    except requests.exceptions.Timeout:
        print("The server took too long to answer.")
    except requests.exceptions.ConnectionError:
        print("Could not connect. Check your internet connection.")
    except requests.exceptions.HTTPError as error:
        print(f"The server refused the request: {error}")
    except requests.exceptions.RequestException as error:
        print(f"The request failed: {error}")
    return None


data = get_json(
    "https://api.open-meteo.com/v1/forecast",
    {"latitude": 951.51, "longitude": -0.13, "current": "temperature_2m"},
)
if data is None:
    print("No forecast today.")

The server refused the request: 400 Client Error: Bad Request for url: https://api.open-meteo.com/v1/forecast?latitude=951.51&longitude=-0.13&current=temperature_2m
No forecast today.

Notice what is not caught: a KeyError from your own code, or a typo that raises NameError. Those are bugs, and you want to see their tracebacks (Day 15). Catch the network’s failures, not your own.

Open-Meteo lets anyone call it, but many APIs do not. They give each user an API key: a long secret string, a bit like a password, that you send with every request so the service knows who is calling. It lets the service limit how often each user calls, and charge for heavy use. That makes a key valuable. Anyone who has yours can use up your limit, or run up your bill, in your name.

So a key must never be written into your code. Code gets shared: you send a file to a friend, post it on a forum to ask for help, or upload a project online. A key written in the file goes with it, and people do search online code for keys. Instead, keep the key outside the program, where only your computer has it, in an environment variable.

An environment variable is a named piece of text that the terminal hands to every program it starts. Your computer already has many, such as PATH, the list of folders where it looks for commands. You set your own in the terminal, before running the program. With a made-up service called Study Facts and a key your-key-here standing in for a real one:

macOS or Linux:      export STUDY_API_KEY="your-key-here"
Windows PowerShell:  $env:STUDY_API_KEY = "your-key-here"
Windows cmd:         set STUDY_API_KEY=your-key-here

Like activating a virtual environment, this lasts only for that one terminal window, until you close it. (Your editor or system settings can store it permanently; the variable’s name is what matters to your program.)

Inside Python, os.environ holds all the environment variables, and it works like a dictionary of strings. Here it is in a terminal where STUDY_API_KEY has not been set:

>>> import os
>>> "STUDY_API_KEY" in os.environ
False
>>> print(os.environ.get("STUDY_API_KEY"))
None
>>> os.environ.get("STUDY_API_KEY", "not set")
'not set'
>>> os.environ["STUDY_API_KEY"]
Traceback (most recent call last):
  ...
KeyError: 'STUDY_API_KEY'

Square brackets raise KeyError for a missing variable, as with any dictionary. os.environ.get(name) returns None instead, so the program can check and give a helpful message:

import os
import sys

api_key = os.environ.get("STUDY_API_KEY")
if api_key is None:
    sys.exit("Set the STUDY_API_KEY environment variable first.")

print("Key found, ending in", api_key[-4:])

Run in a terminal without the variable:

Set the STUDY_API_KEY environment variable first.

api_key is None, so sys.exit (Day 13) stops the program with a message that says exactly what to do. Once the variable is set in that terminal, line 8 runs instead, and prints only the last four characters: enough to tell which key is in use, without showing the secret.

Each API says how to send its key, in its documentation. Two common ways are a query parameter or a header. The requests calls look like this, for the imagined Study Facts API:

response = requests.get(
    "https://api.example.com/v1/facts",
    headers={"Authorization": f"Bearer {api_key}"},
    timeout=10,
)

headers= takes a dictionary of extra request headers, just as params= takes query parameters. The key is read from the environment at run time, so the file holds only the variable’s name, never the secret. A missing or wrong key typically gets a 401 response (22.3).

This command-line tool takes a city name, looks up where it is, and prints the weather there now and for the next three days. It is split into two modules on purpose. report.py turns a parsed response into lines of text and knows nothing about the network:

"""Turn an Open-Meteo forecast response into lines of text."""

from typing import Any


def current_line(data: dict[str, Any]) -> str:
    """Return one line describing the weather right now."""
    current = data["current"]
    units = data["current_units"]
    temperature = f"{current['temperature_2m']} {units['temperature_2m']}"
    wind = f"{current['wind_speed_10m']} {units['wind_speed_10m']}"
    return f"Now: {temperature}, wind {wind}"


def daily_lines(data: dict[str, Any]) -> list[str]:
    """Return one line per day: the date, the low and high, and any rain."""
    daily = data["daily"]
    lines = []
    for date, low, high, rain in zip(
        daily["time"],
        daily["temperature_2m_min"],
        daily["temperature_2m_max"],
        daily["precipitation_sum"],
    ):
        line = f"{date}: {low:.1f} to {high:.1f}"
        if rain > 0:
            line += f", rain {rain:.1f} mm"
        lines.append(line)
    return lines

Because it needs no network, you can try it, and test it (Day 20), on the saved forecast.json:

import json
from pathlib import Path

from report import current_line, daily_lines

data = json.loads(Path("forecast.json").read_text(encoding="utf-8"))
print(current_line(data))
for line in daily_lines(data):
    print(line)

Now: 18.4 °C, wind 12.2 km/h
2026-10-15: 14.6 to 20.9
2026-10-16: 10.0 to 17.2, rain 8.7 mm
2026-10-17: 8.3 to 13.5

weather.py does the network part, using get_json from 22.7 (copy it in above find_place, with its imports):

"""Print the weather for a city: python weather.py CITY"""

import sys
from typing import Any

import requests

from report import current_line, daily_lines

GEOCODE_URL = "https://geocoding-api.open-meteo.com/v1/search"
FORECAST_URL = "https://api.open-meteo.com/v1/forecast"

# get_json from 22.7 goes here.


def find_place(name: str) -> dict[str, Any] | None:
    """Return the best match for a place name, or None."""
    data = get_json(GEOCODE_URL, {"name": name, "count": 1})
    if data is None:
        return None
    results = data.get("results", [])
    if not results:
        print(f"No place called {name}.")
        return None
    return results[0]


def main() -> None:
    if len(sys.argv) != 2:
        sys.exit("Usage: python weather.py CITY")
    place = find_place(sys.argv[1])
    if place is None:
        return
    params = {
        "latitude": place["latitude"],
        "longitude": place["longitude"],
        "current": "temperature_2m,wind_speed_10m",
        "daily": "temperature_2m_max,temperature_2m_min,precipitation_sum",
        "timezone": "auto",
        "forecast_days": 3,
    }
    data = get_json(FORECAST_URL, params)
    if data is None:
        return
    print(f"{place['name']}, {place['country']}")
    print(current_line(data))
    for line in daily_lines(data):
        print(line)


if __name__ == "__main__":
    main()

Run with python weather.py Tokyo (sample output):

Tokyo, Japan
Now: 15.9 °C, wind 4.7 km/h
2026-10-16: 15.9 to 25.9
2026-10-17: 15.8 to 24.1
2026-10-18: 12.8 to 22.6

Keeping the network code thin and the rest of the program in plain functions of plain data is the habit to take away: the part that is hard to test (the internet) is small, and the part with the logic can be tested with saved responses, as many times as you like, with exact answers. A city name with a space needs quotes, as on Day 13: python weather.py "New York".

Use this table to go from what you see to its usual cause. Messages from requests are samples; their wording varies by version.

• A client sends an HTTP request (a method such as GET and a URL), and the server sends a response (a status code, headers, and a body). A web API answers with JSON for programs to use.
• requests.get(url, params=..., timeout=10) sends a request. params= takes a dictionary and URL-encodes it into the query string; headers= adds headers.
• Status codes: 2xx success, 3xx redirect, 4xx a problem with the request, 5xx a problem on the server. requests does not raise for them on its own, so call raise_for_status() before response.json().
• response.json() is json.loads(response.text): chain brackets to reach into nested dictionaries and lists, and use .get() for keys that may be missing. Save a response to a file to work offline.
• The network fails as a matter of course. Always set a timeout, and catch Timeout, ConnectionError, HTTPError, and their parent RequestException, most specific first. Keep API keys in environment variables, read with os.environ.get.

Do these in your day22 folder, with requests installed in your virtual environment (22.2). Type each program yourself, run it, and only then open the answer. Your output will differ from the sample output wherever it comes from a live call.

import requests

response = requests.get(
    "https://geocoding-api.open-meteo.com/v1/search",
    params={"name": "Tokyo", "count": 1},
    timeout=10,
)
response.raise_for_status()
place = response.json()["results"][0]
print("Name:", place["name"])
print("Country:", place["country"])
print("Population:", place["population"])

Name: Tokyo
Country: Japan
Population: 9733276

from typing import Any

import requests

SEARCH_URL = "https://geocoding-api.open-meteo.com/v1/search"


def find_city(name: str) -> dict[str, Any] | None:
    """Return the first place called name, or None on any failure."""
    try:
        response = requests.get(
            SEARCH_URL, params={"name": name, "count": 1}, timeout=10
        )
        response.raise_for_status()
        data = response.json()
    except requests.exceptions.Timeout:
        print("The search took too long. Try again later.")
        return None
    except requests.exceptions.ConnectionError:
        print("Could not connect. Check your internet connection.")
        return None
    except requests.exceptions.RequestException as error:
        print(f"The search failed: {error}")
        return None
    results = data.get("results", [])
    if not results:
        print(f"No place called {name}.")
        return None
    return results[0]


for name in ["Tokyo", "Qzxqzxq"]:
    place = find_city(name)
    if place is not None:
        print(f"{place['name']}, {place['country']}")

Tokyo, Japan
No place called Qzxqzxq.

import json

import requests

response = requests.get(
    "https://geocoding-api.open-meteo.com/v1/search",
    params={"name": "Tokyo", "count": 1},
    timeout=10,
)
response.raise_for_status()
with open("city.json", "w", encoding="utf-8") as file:
    json.dump(response.json(), file, indent=2)
print("Saved city.json")

import json
from pathlib import Path

path = Path("city.json")
if not path.exists():
    print("No saved copy yet: run save_city.py first")
else:
    with path.open(encoding="utf-8") as file:
        data = json.load(file)
    place = data["results"][0]
    print(f"Loaded {path} without the network")
    print("Name:", place["name"])
    print("Country:", place["country"])
    print("Population:", place["population"])

Loaded city.json without the network
Name: Tokyo
Country: Japan
Population: 9733276

import requests

lat, lon = 48.85, 2.35
response = requests.get(
    f"https://api.open-meteo.com/v1/forecast?latitude={lat}&longitude={lon}"
)
data = response.json()
print(data["current"]["temperature_2m"])

import requests

params = {"latitude": 48.85, "longitude": 2.35, "current": "temperature_2m"}
response = requests.get(
    "https://api.open-meteo.com/v1/forecast", params=params, timeout=10
)
response.raise_for_status()
data = response.json()
print(data["current"]["temperature_2m"])

import json

body = """
{"results": [
  {"name": "Springfield", "admin1": "Illinois", "population": 114394},
  {"name": "Springfield", "admin1": "Missouri"}
]}
"""
data = json.loads(body)

for place in data["results"]:
    people = place.get("population", "unknown")
    print(f"{place['name']}, {place['admin1']}: {people}")
known = sum(1 for place in data["results"] if "population" in place)
print(len(data["results"]), "places,", known, "with a population")

Springfield, Illinois: 114394
Springfield, Missouri: unknown
2 places, 1 with a population

The requests documentation’s Quickstart covers today’s tools and a few more, such as sending data with POST. Open-Meteo’s API documentation lists every measurement and query parameter its forecast service accepts.

Check each statement. If the answer is “not yet,” reread the linked subsection.

• I can name the parts of a request and a response, and the parts of a URL. Reread
• I can install requests, fetch a URL, and use status_code, text, and json(). Reread
• I can say what a status code means from its first digit. Reread
• I can explain why raise_for_status() belongs right after requests.get. Reread
• I can reach into nested dictionaries and lists in a JSON response, and use .get() for optional keys. Reread
• I can send query parameters with params= instead of building the URL myself. Reread
• I can set a timeout and catch network errors in the right order. Reread
• I can keep an API key in an environment variable and read it with os.environ.get. Reread