Separate URL, Parameters, and Headers

An HTTP request has several inputs, and joining them into one string hides which part means what. Keep the base and path together, but pass query data through params= and request metadata through headers=.

The items route is /items. Ask for page 2 with a data structure:

document = request_json("/items", params={"page": 2, "page_size": 2})

Requests encodes those values into the URL: the complete URL path is /v1/items and the query is ?page=2&page_size=2. The query selects which page to return; the header below supplies metadata about the request. Your code explicitly supplies only the documented practice metadata:

PRACTICE_HEADERS = {"X-Practice-Name": "python-in-practice"}

Do not add authorization, tokens, host overrides, or public URLs. This service does not define them.

The response includes an HTTP status code describing the outcome. 200 means success, 404 means the requested resource was not found, and 500 means a server error. The body can contain JSON in all three cases, so successfully decoding JSON alone cannot establish success.

Before Lesson 3 turns unsuccessful statuses into exceptions, make the order in request_json visible: read response.status_code, then decode JSON. The value does not need to be returned yet:

    status = response.status_code
    document = response.json()
    return document

Reading a status is not the same as handling it. That temporary line lets you inspect the response boundary without pretending a 404 envelope is successful data. If you manually call /headers, its practice-header field should echo the fixed value. Requests can add ordinary client and protocol headers of its own; they are not extra application metadata chosen by your code.

A fake response can record the order in which your code touched it. That is worth knowing, because it means “did I check the status before decoding?” is a question a test can answer exactly, rather than something you have to take on faith while reading your own code.