Den Status vor JSON prüfen

Eine JSON-Fehlerantwort ist weiterhin eine erfolglose HTTP-Antwort. Code, der zuerst dekodiert, kann {"error": ...} versehentlich wie gewöhnliche Katalogdaten behandeln.

Ersetze das vorübergehende Lesen des Status in request_json durch die Statusprüfung an dieser Grenze:

    response.raise_for_status()
    return response.json()

Die Reihenfolge ist die Vorgabe. Eine 200-Antwort erreicht json(). /items/99, das absichtliche /scenarios/not-found und /scenarios/server-error lösen HTTPError aus, bevor ihr Inhalt als Erfolg missverstanden werden kann.

Fange in request_json nichts ab. Die Funktion kann nicht entscheiden, was ein Befehl ausgeben soll oder welchen Exit-Status der Aufrufer braucht. An der Befehlsgrenze ist dies das eng begrenzte Muster:

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

Lies den Status aus exc.response.status_code, nicht aus dem Ausnahmetext. Das Abschlussprojekt macht aus diesem Wert eine einheitliche Meldung für die Person am Terminal. Unabhängige Programmierfehler müssen weiterhin mit ihrem Traceback nach außen gelangen.

Probiere beide Routen am laufenden internen Dienst aus, wenn du das echte Verhalten sehen möchtest. Schreibe anschließend die Variante mit Fake-Antworten, denn die wird auch in sechs Monaten auf einem Rechner ohne Netzwerk identisch reagieren.

Wenn dir die Reihenfolge willkürlich vorkommt, bitte Monty zu zeigen, was passiert, wenn der JSON-Inhalt einer 404-Antwort wie eine erfolgreiche Seite dekodiert wird. Zu sehen, wie falsche Daten erfolgreich ankommen, überzeugt mehr als die Regel allein.