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

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

https://bildung.social/@oerinformatik/

https://oer-informatik.de/spring-boot-rest-api-fehlerbehandlung-uebungsaufgaben

REST-API, Fehlerbehandlung, Problem Details, RFC 9457, ProblemDetail, RestControllerAdvice, ExceptionHandler, HTTP-Statuscode, Mapper, LazyInitializationException, Übungsaufgaben

tl/dr; (ca. 33 min Lese- und Bearbeitungszeit): Ü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 [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über ein REST-Backend mit Spring Boot: Überblick und Fahrplan / 01 Anforderungen und API-Vertrag / 02 Projekt anlegen / 03 Codegenerierung / 04 Fachlogik und Komponententest / 05 Build-Qualität und CI / 06 Persistenz mit JPA / 07 Repository-Integrationstest / 08 Service und Dependency Injection / 09 REST-API und Fehlerbehandlung / Übungsaufgaben zu 09

Diese Übungsaufgaben gehören zum Artikel Fehler mit Format: restliche Endpunkte, Mapper und Problem Details nach RFC 9457 und setzen den Übungsstrang zu den Mitfahrgesuchen fort. Ausgangspunkt ist das Projekt im Ordner src/09-rest-api-fehlerbehandlung des Repositorys, ergänzt um die Klassen aus den bisherigen Übungen: Zeitfensterregel, Gesuchstatus, die Entity Gesuch (mit Gettern für alle Attribute und der Methode zieheZurueck()), GesuchRepository, NeuesGesuch und GesuchService aus Übung 08. Der GesuchService hat zusätzlich die Methode Optional<Gesuch> finde(Long gesuchId). Die fachlichen Ausnahmen des Übungsstrangs sind so eingeordnet:

Der Vertrag openapi.yaml ist um die Schemas GesuchNeu, Gesuch, GesuchStatus und GesuchStatusAenderung (nur der Wert zurueckgezogen) aus Übung 01 erweitert, dazu um die Operationen stelleGesuchEin (POST /gesuche), holeGesuch (GET /gesuche/{gesuchId}) und aendereGesuch (PATCH /gesuche/{gesuchId}) mit dem Tag gesuche. Im MonitorEintrag darf art jetzt Angebot oder Gesuch sein. Wie in Übung 01 heißt das Feld für die Person im Vertrag mitfahrerId, im Record NeuesGesuch aber nutzerId.

Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1 und Aufgabe 1.2. Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1 und Aufgabe 3.2) keine Probleme bereiten. Notiere Deine Antworten zuerst vollständig, bevor Du die Beispiellösung aufklappst. Code und Tests kannst Du anschließend im Projekt aus dem Repository mit dem Build ausführen; andere fachlich richtige Lösungen sind ebenso richtig.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen? Prompt ein-/ausblenden

Erstelle neue Übungsaufgaben zum Thema „REST-API und Fehlerbehandlung:
Gesuche über die API einstellen“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/spring-boot-rest-api-fehlerbehandlung
- https://oer-informatik.de/rest-grundlagen
- https://oer-informatik.de/spring-boot-anforderungen-api-entwurf
- Stilbeispiel: https://oer-informatik.de/spring-boot-rest-api-fehlerbehandlung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- REST-API
- Fehlerbehandlung
- Problem Details
- RFC 9457
- ProblemDetail
- RestControllerAdvice
- ExceptionHandler
- HTTP-Statuscode
- Mapper
- LazyInitializationException

Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Aufgabe 1.1: Statuscodes für Gesuche zuordnen (Basiskompetenz)

Oksana Melnyk testet die neuen Endpunkte für Gesuche. Ordne jeder Anfrage den Statuscode zu, den das Backend nach dem Vertrag zurückgibt, und begründe kurz. Am Tag des Tests ist Dienstag, der 10.11.2026. (6 Punkte)

Aufgabe 1.2: Eine Fehlerantwort lesen (Basiskompetenz)

Ein Frontend erhält auf eine Anfrage diese Antwort:

HTTP/1.1 409
Content-Type: application/problem+json

{"detail":"Das Gesuch ist nicht mehr offen (Status ZURUECKGEZOGEN).","instance":"/v1/gesuche/1","status":409,"title":"Zustandskonflikt","type":"https://mitfahrlabor.example/probleme/gesuch-nicht-offen"}

1. Nenne die Anfrage (Methode und Pfad), die zu dieser Antwort geführt hat, und erkläre, woran Du das erkennst. (1 Punkt)

2. Das Frontend soll bei diesem Fehler den Hinweis „Dieses Gesuch wurde schon zurückgezogen.“ anzeigen. Begründe, welches Feld es dafür auswerten sollte. (2 Punkte)

3. Ein Teammitglied schlägt vor, bei Fehlern den Stacktrace in detail mitzuschicken, „damit man Fehler schneller findet“. Beurteile den Vorschlag. (1 Punkt)

Aufgabe 2.1: Einen GesuchMapper schreiben (Kernkompetenz)

Das aus dem Vertrag erzeugte Modell api.model.Gesuch hat einen Konstruktor mit allen Pflichtfeldern in dieser Reihenfolge:

public Gesuch(Long mitfahrerId, Long haltepunktId, Richtung richtung, LocalDate datum, String zeitVon,
        String zeitBis, Long id, GesuchStatus status)

GesuchNeu hat die Getter getMitfahrerId(), getHaltepunktId(), getRichtung(), getDatum(), getZeitVon() und getZeitBis(); die Zeiten sind Strings im Format HH:MM.

Schreibe die Klasse GesuchMapper im Paket web nach dem Muster des AngebotMapper mit den Methoden zuApi (Entity Gesuch → api.model.Gesuch) und zuNeuemGesuch (GesuchNeu → NeuesGesuch). Importe musst Du nicht notieren. (7 Punkte)

final class GesuchMapper {

    private GesuchMapper() {
    }

    static Gesuch zuApi(de.dbh.mitfahrlabor.domain.Gesuch g) {
        return new Gesuch(g.getNutzer().getId(), g.getHaltepunkt().getId(),
                Richtung.valueOf(g.getRichtung().name()), g.getDatum(),
                g.getZeitVon().toString(), g.getZeitBis().toString(),
                g.getId(), GesuchStatus.valueOf(g.getStatus().name()));
    }

    static NeuesGesuch zuNeuemGesuch(GesuchNeu neu) {
        return new NeuesGesuch(neu.getMitfahrerId(), neu.getHaltepunktId(),
                AngebotMapper.zuFahrtrichtung(neu.getRichtung()), neu.getDatum(),
                LocalTime.parse(neu.getZeitVon()), LocalTime.parse(neu.getZeitBis()));
    }
}

Aufgabe 2.2: Einen GesuchController schreiben (Kernkompetenz)

1. Schreibe die Klasse GesuchController, die die erzeugte Schnittstelle GesucheApi implementiert. Sie soll Gesuche einstellen (201 mit Location-Header /v1/gesuche/{id}), abrufen (unbekannte ID: 404 mit Problem Details) und zurückziehen. Die Methoden der Schnittstelle heißen wie die operationId; aendereGesuch bekommt die ID und ein GesuchStatusAenderung. Importe musst Du nicht notieren. (6 Punkte)

2. Begründe, warum die Klasse ProblemBehandlung für die neuen Endpunkte nicht geändert werden muss, obwohl drei neue fachliche Ausnahmen dazukommen. (2 Punkte)

@RestController
public class GesuchController implements GesucheApi {

    private final GesuchService gesuchService;

    public GesuchController(GesuchService gesuchService) {
        this.gesuchService = gesuchService;
    }

    @Override
    public ResponseEntity<Gesuch> stelleGesuchEin(GesuchNeu neu) {
        var gesuch = gesuchService.stelleEin(GesuchMapper.zuNeuemGesuch(neu));
        return ResponseEntity.created(URI.create("/v1/gesuche/" + gesuch.getId()))
                .body(GesuchMapper.zuApi(gesuch));
    }

    @Override
    public ResponseEntity<Gesuch> holeGesuch(Long gesuchId) {
        return gesuchService.finde(gesuchId)
                .map(GesuchMapper::zuApi)
                .map(ResponseEntity::ok)
                .orElseThrow(() -> new NichtGefundenException("Gesuch", gesuchId));
    }

    @Override
    public ResponseEntity<Gesuch> aendereGesuch(Long gesuchId, GesuchStatusAenderung aenderung) {
        return ResponseEntity.ok(GesuchMapper.zuApi(gesuchService.zieheZurueck(gesuchId)));
    }
}

Aufgabe 3.1: Der Flurmonitor zeigt Gesuche und meldet 500 (Profilkompetenz)

Ein Teammitglied erweitert den Flurmonitor um offene Gesuche. Im GesuchRepository kommt eine abgeleitete Abfragemethode hinzu, der MonitorService bekommt eine neue Methode, und der MonitorMapper wandelt Gesuche um:

    // GesuchRepository
    List<Gesuch> findByStatusAndDatumGreaterThanEqualOrderByDatumAscZeitVonAsc(Gesuchstatus status,
            LocalDate ab, Limit limit);

    // MonitorService (Klasse mit @Transactional(readOnly = true))
    public List<Gesuch> naechsteGesuche(int max) {
        return gesuchRepository.findByStatusAndDatumGreaterThanEqualOrderByDatumAscZeitVonAsc(Gesuchstatus.OFFEN,
                LocalDate.now(uhr), Limit.of(max));
    }

    // MonitorMapper
    static MonitorEintrag zuEintrag(de.dbh.mitfahrlabor.domain.Gesuch g) {
        return new MonitorEintrag(MonitorEintrag.ArtEnum.GESUCH, g.getHaltepunkt().getOrt(),
                g.getHaltepunkt().getName(), Richtung.valueOf(g.getRichtung().name()), g.getDatum(),
                g.getZeitVon().toString(), 1);
    }

Der MonitorController ruft monitorService.naechsteGesuche(max) auf und wandelt das Ergebnis mit MonitorMapper::zuEintrag um. Alle Tests sind grün, doch GET /v1/monitor/eintraege antwortet mit 500. Im Log steht:

org.hibernate.LazyInitializationException: Could not initialize proxy [de.dbh.mitfahrlabor.domain.Haltepunkt#1] - no session

1. Erkläre, wie es zu der Ausnahme kommt. (2 Punkte)

2. Behebe den Fehler im GesuchRepository. (2 Punkte)

3. Ein anderes Teammitglied schlägt vor, einfach spring.jpa.open-in-view=true zu setzen; das funktioniert tatsächlich. Bewerte den Vorschlag. (2 Punkte)

    @Query("""
            select g from Gesuch g join fetch g.haltepunkt
            where g.status = :status and g.datum >= :ab
            order by g.datum, g.zeitVon
            """)
    List<Gesuch> findeFuerMonitor(@Param("status") Gesuchstatus status, @Param("ab") LocalDate ab, Limit limit);

Aufgabe 3.2: Der Statuscode in der Ausnahme? (Profilkompetenz)

Ein Teammitglied findet drei @ExceptionHandler-Methoden umständlich und schlägt vor:

public abstract class MitfahrlaborException extends RuntimeException {

    protected MitfahrlaborException(String meldung) {
        super(meldung);
    }

    /** Jede Ausnahme kennt ihren HTTP-Statuscode selbst. */
    public abstract HttpStatus httpStatus();
}

Die ProblemBehandlung hätte dann nur noch eine Methode @ExceptionHandler ProblemDetail behandle(MitfahrlaborException e), die e.httpStatus() verwendet.

1. Nenne einen Vorteil des Vorschlags. (1 Punkt)

2. Bewerte den Vorschlag im Hinblick auf die Schichten der Anwendung. (2 Punkte)

3. Eine neue Ausnahme GesuchAbgelaufenException soll entstehen. Erkläre, wie die bestehende Lösung mit drei Oberklassen dafür sorgt, dass sie den richtigen Statuscode bekommt, und was Entwickler*innen dafür entscheiden müssen. (2 Punkte)

Links und weitere Informationen

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

• als Grundlage: REST-Grundlagen und Anforderungen und API-Vertrag

• als Nachschlagewerk: RFC 9457 – Problem Details for HTTP APIs und Spring Framework – Error Responses

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu REST-API und Fehlerbehandlung: Gesuche über die API einstellen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/spring-boot-rest-api-fehlerbehandlung-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/java-springboot/Backend. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]