Lehne fehlerhafte Anfragen nach Ursache ab

Deine Schreibzugriffe funktionieren für gültige Bücher, und nur für diese. Sende die fehlerhaften Anfragen des Hilfsprogramms und sieh zu, was passiert:

python pl_http.py bad-requests

Die erste Anfrage ist POST /books mit dem Body title=Dune, gekennzeichnet als text/plain. handle ruft create_book auf, das json_body aufruft, das eine Ausnahme auslöst. Die Antwortzeile im Protokoll lautet (no bytes: the server closed the connection without answering), und der Log-Block enthält einen Traceback, der mit json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) endet. Wenn handle eine Ausnahme auslöst, gibt http.server den Traceback aus und schließt die Verbindung ohne Antwort, also erfährt der Client nichts. pl_http hört nach dieser Anfrage auf zu senden und sagt das.

Eine JSON-Liste käme weiter und würde bei data["title"] scheitern; ein Buch mit leerem Titel würde gespeichert. Jede fehlerhafte Anfrage braucht einen Status, der benennt, was falsch ist, und keine davon darf den Zustand verändern.

Status nach Ursache

SERVICE_CONTRACT.md listet diese Prüfungen auf, und die erste, die fehlschlägt, entscheidet die Antwort. Hier sind sie in der Reihenfolge, in der der Server sie ausführt:

Eine Anfrage, die jede Zeile besteht, erreicht den Schreibzugriff und bekommt 201, 200 oder 204. Zwei Zeilen brauchen ein Wort zu ihrem Platz. Die Rahmung kommt vor der Route, weil read_body im Adapter läuft, bevor handle irgendetwas sieht: Deshalb bekommt ein POST /nowhere ohne Länge 411, nicht 404. Und die Buch-ID kommt vor dem Body, also ist ein PUT an ein Buch, das nicht existiert, eine 404, egal was sein Body sagt. Verfolge im Diagramm eine fehlerhafte Anfrage die Prüfungen hinunter, bis sie rechts hinausgeht:

400 oder 422

Eine 400 und eine 422 können beide auf einen fehlerhaften Body antworten; der Unterschied ist, wie weit der Server gekommen ist. 400 Bad Request sagt, dass die Anfrage überhaupt nicht gelesen werden konnte: Diese Bytes lassen sich nicht als JSON parsen. 422 Unprocessable Content sagt, dass der Server sie problemlos gelesen hat und nicht tun kann, was sie verlangt (RFC 9110, Abschnitt 15.5.21): Das JSON ist gültig, aber es ist eine Liste, wo ein Objekt hingehört, oder sein Titel ist 7, oder sein Autor besteht aus drei Leerzeichen.

Die Form zu prüfen heißt, Typen zu prüfen. isinstance(value, dict) fragt, ob ein Wert ein Dictionary ist, also das, was aus einem JSON-Objekt wird; isinstance(value, str) fragt, ob er ein String ist. Ein Titel, der leer ist, sobald strip() die Leerzeichen entfernt hat, ist so leer wie "".

print(isinstance([1, 2], dict), isinstance({"title": 3}["title"], str))

Erst prüfen, dann ändern

book_error(data) prüft einen dekodierten Wert: kein Dictionary, ein fehlendes title oder author oder eins davon, das kein nicht leerer String ist, bekommt jeweils eine 422, deren Fehler das Problem benennt. Schreib jede Meldung für die Person, die die Antwort liest: author is missing sagt ihr, was sie ändern muss, und bad request nicht. Du kannst title oder author zuerst prüfen; so oder so wird das erste gefundene Problem gemeldet. book_request_error(request) führt die ganze Body-Prüfung aus: zuerst body_error, und nur wenn das nichts findet, book_error(json_body(request)). Jede gibt None oder die zu sendende Antwort zurück, wie read_body und body_error, also behält handle den ersten Fehler, den es bekommt:

response = book_request_error(request)
if response is None:
    response = create_book(request, state)

Die Reihenfolge darin zählt doppelt. book_error darf nicht auf Bytes laufen, die body_error abgelehnt hat, weil json_body bei ihnen eine Ausnahme auslösen würde. Und create_book darf nicht laufen, bevor jede Prüfung bestanden ist: Ein gespeichertes Buch oder ein hochgezähltes next_id vor einer 422 wäre eine Änderung, von der man dem Client gesagt hat, sie sei nicht passiert.

Deine Aufgabe

In reading_server.py:

1. Schreib book_error(data): Gib eine 422-Antwort zurück, gebaut mit json_error, wenn data kein Dictionary ist, wenn title oder author fehlt oder wenn eins davon kein String ist oder nach dem Entfernen der Leerzeichen leer ist. Andernfalls gib None zurück.

2. Schreib book_request_error(request): Gib body_error(request) zurück, wenn es nicht None ist; andernfalls gib book_error(json_body(request)) zurück.

3. Ruf in handle book_request_error vor create_book und vor replace_book auf und sende seine Antwort, wenn es eine zurückgibt.

Führ python pl_http.py bad-requests noch einmal aus. Jede Anfrage bekommt jetzt ihre eigene Antwort: HTTP/1.0 415 Unsupported Media Type für den text/plain-Body, HTTP/1.0 400 Bad Request für das abgeschnittene JSON, HTTP/1.0 422 Unprocessable Content für die Liste, HTTP/1.0 404 Not Found für das PUT an Buch 99 und HTTP/1.0 411 Length Required für das POST ohne Länge, das dein read_body beantwortet hat, bevor handle lief.

Drück dann Check my work. Dein Server lehnt jetzt jeden fehlerhaften Schreibzugriff mit einem Grund ab; die nächste Lektion beweist mit eigenen Tests, dass die guten Schreibzugriffe ihre Versprechen halten.