0%

Der Standard-Client und die Statusklassen

Zuerst nach der Klasse entscheiden

get_json gibt jeden Status zurück, der angekommen ist. Bei der ersten Seite der Einträge ist das 200, aber dieselbe gibt 404 für einen Eintrag zurück, den es nicht gibt, 429, wenn du zu oft fragst, und 504, wenn ein Server weiter hinten in der Kette aufgibt. Ein Client braucht eine Regel dafür, was als Nächstes zu tun ist, und diese Regel kann keine aller Codes sein: Es gibt Dutzende, neue werden definiert, und ein Server kann einen senden, für den dein Client nie geschrieben wurde. legt die Regel in den Code selbst, in seine erste Ziffer.

Fünf Klassen

Ein besteht aus drei Ziffern, und die erste nennt seine Klasse:

CodesKlasseWas sie dem Client sagtWas der Client als Nächstes tut
1xxinformativder Server hat noch mehr zu sagen; das ist noch nicht die Antwortauf die endgültige Antwort warten, die folgt
2xxErfolgdie Anfrage hat funktioniertdie Antwort benutzen
3xxdie Antwort liegt woanderssich den Header Location ansehen; Kapitel 6 folgt ihm
4xxClientfehleretwas an der Anfrage war falschdie Anfrage ändern, bevor sie noch einmal gesendet wird; bei 429 Too Many Requests mindestens so lange warten, wie Retry-After sagt
5xxServerfehlerder Server hat eine Anfrage nicht beantworten können, die in Ordnung sein kannein späterer Versuch kann funktionieren; dieser Kurs wiederholt nicht

Die Klasse beantwortet die erste Frage, die jeder Client hat: Hat es funktioniert, und wenn nicht, wer ist am Zug? Ein 4xx sagt, dass du am Zug bist, weil der Server nicht handeln wird, bis sich etwas an der Anfrage ändert, oder daran, wann du sie sendest. Ein 5xx sagt, dass der Server versagt hat; deine Anfrage war vielleicht in Ordnung. Der genaue Code fügt innerhalb der Klasse Details hinzu. Ein 404 sagt, dass das, wonach du gefragt hast, nicht da ist, 401 und 403 betreffen, wer du bist und was du darfst (Kapitel 7 unterscheidet sie), und 301, 307 und 308 sagen, wie einer Weiterleitung gefolgt werden soll (Kapitel 6).

Warum die Klasse zuerst kommt

Die Definition von HTTP (RFC 9110, Abschnitt 15) verlangt von jedem Client, die Klasse jedes Codes zu verstehen und einen Code, den er nicht kennt, wie den x00-Code seiner Klasse zu behandeln. Ein Client, der nie von 299 gehört hat, behandelt es wie 200, und einer, der nie von 451 gehört hat, behandelt es wie 400. Ein Client, der zuerst nach der Klasse entscheidet, steckt also nie fest: Er hat eine Antwort für jeden Code, auch für Codes, die erfunden wurden, nachdem er geschrieben wurde. Er kann sich danach trotzdem den genauen Code ansehen, wie er es bei 429 tun wird.

Die Klasse zu finden braucht eine Operation, die du aus Python Fundamentals kennst: Ganzzahldivision durch 100 lässt die letzten beiden Ziffern wegfallen. Sobald du die Klasse hast, beantwortet ein Vergleich die Frage “hat es funktioniert?”:

Try it

Nur 204 gibt True aus: Es ist der einzige Erfolg unter den vier, obwohl es keinen Body trägt.

Was raise_for_status getan hat

In Python in der Praxis hat response.raise_for_status() jedes 4xx und 5xx in eine verwandelt, bevor dein Code den Body dekodiert hat. Das ist die Klassenregel in ihrer kürzesten Form: Erfolg oder nicht. Das hat seinen Preis: Dein Code hat den Fehler-Body nie dekodiert. Ein Fehler-Body sagt oft, was falsch war, etwa welcher außerhalb des Bereichs lag, und ein Client, der eine Ausnahme auslöst, bevor er ihn ansieht, wirft das weg. Lektion 4 behält den Body jeder Antwort und hängt stattdessen die Klasse daran.

Dein Client empfängt 299, einen Code, den er nie gesehen hat. Was sollte er tun?

Eine Antwort sagt 429 Too Many Requests. Welche Klasse ist das, und was sollte ein Client als Nächstes tun?

Was gibt das aus?

for code in [101, 304, 451, 500]:
    print(code, code // 100)

Du hast jetzt eine Regel für jeden Status. Manche Entscheidungen brauchen mehr als den Status, etwa wie lange nach einem 429 zu warten ist, und diese Information kommt in den Antwort-Headern. Die nächste Lektion liest sie.