0%

Met een API communiceren · oefening

Controleer de status vóór JSON

Een JSON-antwoord met een fout blijft een onsuccesvol HTTP-antwoord. Code die eerst decodeert kan {"error": ...} per ongeluk behandelen als gewone catalogusgegevens.

Vervang het tijdelijke uitlezen van de status in request_json door de statuscontrole:

    response.raise_for_status()
    return response.json()

De volgorde is het contract. Een 200 bereikt json(). /items/99, de bewuste /scenarios/not-found en /scenarios/server-error werpen HTTPError op voordat hun inhoud voor succes kan worden aangezien.

Vang niets op binnen request_json. Die functie kan niet beslissen wat een commando moet afdrukken of welke afsluitstatus de aanroeper nodig heeft. Bij de commandogrens is dit het gerichte patroon:

try:
    document = request_json("/items/99")
except requests.HTTPError as exc:
    print(exc.response.status_code)

Lees de status uit exc.response.status_code, niet uit de exceptietekst. Het slotproject zet die waarde om in één vaste melding voor de gebruiker. Andere programmeerfouten moeten nog steeds met hun traceback verdergaan.

Probeer beide routes tegen de live interne dienst als je het echte gedrag wilt zien. Schrijf daarna de versie met een namaakantwoord, want die gedraagt zich over een halfjaar nog hetzelfde op een computer zonder netwerk.

Waarom roep je raise_for_status() vóór json() aan?

Als de volgorderegel willekeurig voelt, vraag Monty dan te laten zien wat er gebeurt wanneer de JSON-inhoud van een 404 wordt gedecodeerd alsof het een geslaagde pagina is. Verkeerde gegevens probleemloos zien binnenkomen overtuigt meer dan de regel alleen.

Opdracht

Verander request_json zodat die response.raise_for_status() vóór response.json() aanroept en niets opvangt. Behoud de vaste URL, exacte header, doorgegeven parameters, één-aanroepgedrag en expliciete time-out.