0%

De standaardclient en statusklassen

Beslis eerst op klasse

get_json geeft elke status terug die aankwam. Op de eerste pagina met items is dat 200, maar dezelfde geeft een 404 terug voor een item dat niet bestaat, een 429 als je te vaak vraagt, en een 504 als een server verderop het opgeeft. Een client heeft een regel nodig voor wat hij daarna doet, en die regel kan geen van elke code zijn: er zijn er tientallen, er worden nieuwe gedefinieerd, en een server kan er een sturen waarvoor je client nooit geschreven is. stopt de regel in de code zelf, in het eerste cijfer.

Vijf klassen

Een bestaat uit drie cijfers, en het eerste noemt de klasse:

CodesKlasseWat het de client verteltWat de client daarna doet
1xxinformatiefde server heeft meer te zeggen; dit is nog niet het antwoordwachten op het definitieve antwoord dat volgt
2xxsucceshet verzoek werktehet antwoord gebruiken
3xxhet antwoord staat ergens andersnaar de header Location kijken; hoofdstuk 6 volgt hem
4xxclientfouter was iets mis met het verzoekhet verzoek veranderen voordat je het opnieuw verstuurt; bij 429 Too Many Requests minstens zo lang wachten als Retry-After zegt
5xxserverfoutde server kon een verzoek dat misschien in orde is niet beantwoordenlater opnieuw proberen kan werken; deze cursus probeert niet opnieuw

De klasse beantwoordt de eerste vraag die elke client heeft: werkte het, en zo niet, wie is er aan zet? Een 4xx zegt dat jij aan zet bent, omdat de server niets doet totdat er iets aan het verzoek, of aan wanneer je het verstuurt, verandert. Een 5xx zegt dat de server faalde; je verzoek was misschien in orde. De exacte code voegt binnen de klasse details toe. Een 404 zegt dat wat je vroeg er niet is, 401 en 403 gaan over wie je bent en wat je mag (hoofdstuk 7 legt het verschil uit), en 301, 307 en 308 zeggen hoe een doorverwijzing gevolgd moet worden (hoofdstuk 6).

Waarom de klasse eerst komt

De definitie van HTTP (RFC 9110, sectie 15) vraagt elke client de klasse van elke code te begrijpen, en een code die hij niet herkent te behandelen als de x00-code van zijn klasse. Een client die nooit van 299 heeft gehoord, behandelt hem als 200, en een die nooit van 451 heeft gehoord, behandelt hem als 400. Een client die eerst op klasse beslist, loopt dus nooit vast: hij heeft een antwoord op elke code, ook op codes die zijn bedacht nadat hij geschreven werd. Hij kan daarna nog steeds naar de exacte code kijken, zoals hij voor 429 zal doen.

De klasse vinden kost één bewerking die je kent uit Python Fundamentals: afrondend delen door 100 laat de laatste twee cijfers vallen. Heb je de klasse eenmaal, dan beantwoordt één vergelijking de vraag “werkte het?”:

Try it

Alleen 204 drukt True af: het is het enige succes van de vier, ook al heeft het geen body.

Wat raise_for_status deed

In Python in Practice maakte response.raise_for_status() van elke 4xx en 5xx een voordat je code de body decodeerde. Dat is de klasseregel in zijn kortste vorm: succes of niet. Het heeft een prijs: je code decodeerde de foutbody nooit. Een foutbody zegt vaak wat er mis was, zoals welke buiten bereik lag, en een client die een exception opwerpt voordat hij ernaar kijkt, gooit dat weg. Les 4 houdt de body van elk antwoord en hangt er in plaats daarvan de klasse aan.

Je client ontvangt 299, een code die hij nooit heeft gezien. Wat moet hij doen?

Een antwoord zegt 429 Too Many Requests. Welke klasse is het, en wat moet een client daarna doen?

Wat drukt dit af?

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

Je hebt nu een regel voor elke status. Sommige beslissingen hebben meer nodig dan de status, zoals hoe lang je na een 429 wacht, en die informatie komt in de headers van het antwoord. De volgende les leest ze.