Fehlerbehandlung

Automatisch aktualisieren: Der Flurmonitor lädt seine Tabellen selbst nach

Bisher zeigt der Flurmonitor denselben Stand, bis jemand die Seite neu lädt. In diesem Artikel lädt die Seite zuerst per Meta-Refresh komplett neu, dann holt ein kleines Skript mit fetch alle 30 Sekunden nur den Bereich mit den Abfahrten. Der Controller liefert dafür ein Thymeleaf-Fragment unter einer eigenen Adresse. Scheitert das Nachladen, bleibt der letzte Stand mit einem Hinweis stehen. Damit vier Monitore die Datenbank nicht im Sekundentakt befragen, legt @Cacheable die Abfrage für 20 Sekunden in einen Caffeine-Cache, und @CacheEvict leert ihn, sobald sich ein Angebot ändert.

Fehler mit Format: restliche Endpunkte, Mapper und Problem Details nach RFC 9457

Seit Artikel 08 greifen die Fachregeln, aber jeder Verstoß endet als 500 Internal Server Error. Jetzt bekommt jede fachliche Ausnahme den Statuscode aus dem Vertrag: 404, 409 oder 422, beschrieben als Problem Details nach RFC 9457. Eine zentrale Klasse mit @RestControllerAdvice übernimmt das für alle Controller, auch für Vertragsverstöße (400). Dazu kommen die restlichen Endpunkte (Angebot ändern und absagen, Buchungen eines Angebots, Flurmonitor) und eigene Mapper-Klassen für die Umwandlung zwischen Entities und Vertragsmodellen.

Übungsaufgaben zu REST-API und Fehlerbehandlung: Gesuche über die API einstellen

Übungen zur Fehlerbehandlung im Mitfahr-Backend: Du ordnest Fehlersituationen rund um Mitfahrgesuche den Statuscodes zu, liest eine Fehlerantwort nach RFC 9457, schreibst einen GesuchMapper und einen GesuchController, findest heraus, warum der Flurmonitor mit Gesuchen plötzlich 500 meldet, und bewertest einen Vorschlag, den Statuscode in die fachlichen Ausnahmen zu verlagern.