Backend für Applikationen realisieren

Das Backend ist der Teil einer Applikation, den niemand sieht, auf den sich aber alle verlassen. Du entwirfst eine REST-API mit sinnvollen Ressourcen, HTTP-Methoden und Statuscodes und setzt sie mit einem Framework wie Spring Boot oder ASP.NET Core um. Die Daten speicherst du über ein ORM in einer relationalen Datenbank. Du validierst Eingaben, gibst verständliche Fehler zurück, schützt Endpunkte mit Authentifizierung und Rollen und prüfst alles mit Tests und einer OpenAPI-Dokumentation.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Eine REST-Schnittstelle fachlich sauber entwerfen

   Kompetenz A

   Du leitest aus einer Anforderung Ressourcen ab, wählst sprechende URLs im Plural und ordnest jeder Aktion die passende HTTP-Methode und die richtigen Statuscodes zu. So können andere die API nutzen, ohne dich fragen zu müssen.

   Situation

   Ein Sportverein mit 300 Mitgliedern möchte die Hallenbelegung online verwalten. Ein Frontend-Team wartet auf deine API.

   Deine Aufgabe

   Entwirf die Endpunkte für Hallen und Reservationen.

   Gutes Ergebnis

   GET /hallen, GET /hallen/{id}/reservationen?datum=2026-11-03, POST /reservationen (Antwort 201 mit Location-Header), DELETE /reservationen/{id} (204). Eine Doppelbuchung führt zu 409 Conflict mit einer klaren Meldung.

   RessourceHTTP-MethodenStatuscodesPfad- und Query-ParameterIdempotenzDTO
2. 2

   Endpunkte in einer klaren Schichtenarchitektur umsetzen

   Kompetenz B

   Du trennst Controller (HTTP), Service (Geschäftslogik) und Repository (Datenzugriff). Der Controller nimmt nur Anfragen entgegen und gibt Antworten zurück, Regeln stehen im Service. So bleibt der Code testbar und änderbar.

   Situation

   Im Lagersystem eines Onlinehändlers für Velozubehör steckt die ganze Bestelllogik in einem 600 Zeilen langen Controller.

   Deine Aufgabe

   Setze den Endpunkt POST /bestellungen neu in drei Schichten um.

   Gutes Ergebnis

   BestellController nimmt ein BestellungRequest-DTO an. BestellService prüft den Lagerbestand, berechnet den Total inkl. 8.1 % MWST und speichert über das BestellRepository. Der Controller gibt 201 mit der neuen Bestell-ID zurück.

   ControllerServiceRepositoryDependency InjectionDTO vs. Entity
3. 3

   Daten über ein ORM in einer relationalen Datenbank speichern

   Kompetenz B

   Du bildest Tabellen als Entity-Klassen ab, definierst Beziehungen und lässt das ORM die SQL-Befehle erzeugen. Du weisst, welche Abfragen dabei entstehen, und erkennst Performance-Fallen.

   Situation

   Die Hallenreservation soll in PostgreSQL gespeichert werden. Jede Reservation gehört zu einer Halle und einem Mitglied.

   Deine Aufgabe

   Lege die Entities an und schreibe eine Abfrage für alle Reservationen einer Halle an einem Tag.

   Gutes Ergebnis

   Entities Halle, Mitglied und Reservation mit @ManyToOne-Beziehungen. Im Repository eine Methode 'findByHalleIdAndDatum(hallenId, datum)'. Im SQL-Log sieht man genau eine Abfrage mit WHERE auf halle_id und datum.

   EntityORMBeziehungen (1:n, n:m)Repository-PatternMigrationenN+1-Problem
4. 4

   Eingaben prüfen und Fehler einheitlich zurückgeben

   Kompetenz C

   Du validierst jede Anfrage auf dem Server, egal was das Frontend bereits prüft. Fehler gibst du in einem einheitlichen JSON-Format mit passendem Statuscode zurück, statt Stacktraces an den Client zu senden.

   Situation

   Bei der Hallenreservation kommen Anfragen mit Endzeit vor Startzeit und mit nicht existierenden Hallen-IDs an. Der Server antwortet mit 500 und einem Java-Stacktrace.

   Deine Aufgabe

   Sorge für saubere Validierung und Fehlerantworten.

   Gutes Ergebnis

   Bean-Validation-Annotationen auf dem Request-DTO, eine eigene Prüfung 'Ende nach Start' im Service und ein globaler Exception-Handler. Ungültige Daten liefern 400 mit {"feld": "ende", "meldung": "muss nach Start liegen"}, unbekannte Halle 404.

   Serverseitige ValidierungBean Validation / Data AnnotationsException-HandlerFehlerformat (Problem Details)400 vs. 404 vs. 500
5. 5

   Endpunkte mit Authentifizierung und Rollen schützen

   Kompetenz D

   Du stellst sicher, dass nur angemeldete Personen die API nutzen und dass sie nur das dürfen, was ihre Rolle erlaubt. Passwörter speicherst du nur als Hash, Tokens prüfst du bei jeder Anfrage.

   Situation

   In der Hallenreservation sollen Mitglieder nur eigene Reservationen löschen dürfen, der Vorstand alle.

   Deine Aufgabe

   Sichere die API ab und setze die Regel durch.

   Gutes Ergebnis

   Login unter POST /auth/login liefert ein JWT. Alle anderen Endpunkte verlangen das Token im Authorization-Header. DELETE /reservationen/{id} gibt 403 zurück, wenn das Mitglied nicht Besitzer ist und nicht die Rolle VORSTAND hat. Passwörter liegen als bcrypt-Hash in der Datenbank.

   Authentifizierung vs. AutorisierungJWTRollenPasswort-Hashing (bcrypt)401 vs. 403Secrets in Umgebungsvariablen
6. 6

   Die API testen und für andere dokumentieren

   Kompetenz E

   Du prüfst Endpunkte mit Postman-Collections und automatisierten Integrationstests, inklusive Fehlerfällen. Aus dem Code erzeugst du eine OpenAPI-Beschreibung, die das Frontend-Team direkt in Swagger UI ausprobieren kann.

   Situation

   Das Frontend-Team der Hallenreservation fragt täglich, welche Felder ein Endpunkt erwartet und welche Fehler kommen können.

   Deine Aufgabe

   Stelle eine Dokumentation und Tests bereit, die mit dem Code mitwachsen.

   Gutes Ergebnis

   Springdoc (Spring Boot) bzw. Microsoft.AspNetCore.OpenApi mit einer Oberfläche wie Swashbuckle oder Scalar (ASP.NET Core) erzeugt eine interaktive Swagger-UI mit allen Endpunkten und Beispielen. Eine Postman-Collection deckt Erfolg, 400, 401, 403 und 409 ab. Fünf Integrationstests mit Testcontainers laufen in der CI bei jedem Push.

   Postman-CollectionIntegrationstestTestdatenbankOpenAPI / SwaggerTestabdeckung der Fehlerfälle

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Gian ist im 2. Lehrjahr als Informatiker Applikationsentwicklung bei der Frischvomhof AG in Sursee, einem Startup mit 20 Mitarbeitenden, das Bauernhöfe mit Kundschaft aus der Region verbindet. Heute bestellen Kundinnen und Kunden Eier, Käse und Gemüse per Telefon oder WhatsApp direkt beim Hof. Gian soll das Backend für eine Plattform bauen, auf der Höfe ihre Produkte pflegen und Kunden Bestellungen zur Abholung aufgeben.

1. Kapitel 1

   Höfe, Produkte, Bestellungen

   Gian legt die Ressourcen /hoefe, /produkte und /bestellungen fest. Sein erster Entwurf enthält Pfade wie /getProdukte und /deleteBestellung, worauf ihn die Teamleiterin im Review auf die HTTP-Methoden hinweist. Er überarbeitet den Entwurf und definiert 201 mit Location-Header für neue Bestellungen und 409, wenn ein Produkt ausverkauft ist. Die OpenAPI-Skizze schickt er dem App-Team, bevor er eine Zeile Code schreibt.

   Ziel 1

2. Kapitel 2

   Vom Speicher in die Datenbank

   Gian baut die API mit Spring Boot in den Schichten Controller, Service und Repository und startet PostgreSQL per docker compose. Ein Hof hat viele Produkte, eine Bestellung viele Positionen. Die Bestellliste eines Hofs braucht zwei Sekunden, und im Log sieht er für jede Position eine eigene Abfrage, was er mit einem JOIN FETCH behebt. Den Bestandsabzug und das Speichern der Bestellung fasst er in eine Transaktion, damit nie nur die Hälfte gespeichert wird.

   Ziel 2Ziel 3

3. Kapitel 3

   Minus drei Eier

   Ein Tester bestellt minus drei Eier, und die API erhöht dabei den Lagerbestand. Gian ergänzt die DTOs mit Regeln wie @Positive und prüft im Service, dass das Abholdatum in der Zukunft liegt und auf einen Öffnungstag des Hofs fällt. Bisher kam bei Fehlern ein Stacktrace mit Tabellennamen zurück. Ein globaler Exception-Handler liefert jetzt ein einheitliches Problem-Details-JSON mit einer Liste der fehlerhaften Felder.

   Ziel 4

4. Kapitel 4

   Nur der eigene Hof

   Gian führt die Rollen KUNDE und HOF ein, speichert Passwörter mit bcrypt und gibt beim Login ein JWT aus. Im Test ändert eine Bäuerin von Hof 3 mit ihrem eigenen Token die Preise von Hof 5, und die API lässt es zu. Gian ergänzt im Service eine Besitzprüfung, die in diesem Fall 403 zurückgibt. Abgelaufene Tokens werden mit 401 abgewiesen, was er mit einem bewusst manipulierten Token prüft.

   Ziel 5

5. Kapitel 5

   Übergabe ans App-Team

   Gian schreibt 18 Integrationstests mit Testcontainers für Erfolgsfälle, Validierungsfehler, 403 und 409. Dabei deckt ein Test auf, dass eine stornierte Bestellung den Lagerbestand nicht zurückbucht, und er korrigiert den Fehler. In Swagger UI ergänzt er Beispiele für jede Anfrage und jede Fehlerantwort. Das App-Team bindet die Schnittstelle danach in zwei Tagen an, ohne eine einzige Rückfrage zu stellen.

   Ziel 6

1. 1

   HTTP verstehen

   ca. 3 Std.

   Bevor du selbst eine API baust, untersuchst du bestehende: Was steht im Request, was in der Response, und warum gibt es welche Statuscodes?

   • Mit Postman eine öffentliche API wie transport.opendata.ch abfragen und Header, Body und Status notieren
   • Für ein Thema deiner Wahl (Bibliothek, Kantine, Werkstatt) Ressourcen und Endpunkte auf Papier entwerfen

   Trainiert Kompetenz A1

   Lernziel1

2. 2

   Erste API mit dem Framework

   ca. 5 Std.

   Du erzeugst ein Projekt mit Spring Initializr oder 'dotnet new webapi' und setzt erste Endpunkte mit Daten im Speicher um.

   • CRUD-Endpunkte für eine Ressource mit einer Liste im Speicher umsetzen
   • Controller und Service trennen und den Service per Dependency Injection einbinden
   • Alle Endpunkte in einer Postman-Collection festhalten

   Trainiert Kompetenz B1A2

   Lernziel21

3. 3

   Datenbank anbinden

   ca. 6 Std.

   Du ersetzt die Liste im Speicher durch eine echte Datenbank, die du mit Docker startest, und arbeitest mit Entities und Repositories.

   • MySQL oder PostgreSQL per docker compose starten
   • Zwei Entities mit einer 1:n-Beziehung anlegen und das erzeugte SQL im Log prüfen
   • Eine eigene Abfrage-Methode im Repository ergänzen

   Trainiert Kompetenz B2

   Lernziel3

4. 4

   Validierung und Fehlerbehandlung

   ca. 4 Std.

   Du machst die API robust: ungültige Eingaben, fehlende Datensätze und Konflikte werden sauber beantwortet.

   • DTOs mit Validierungsregeln versehen
   • Einen globalen Exception-Handler mit einheitlichem Fehlerformat bauen
   • Mit Postman bewusst kaputte Anfragen schicken und die Antworten prüfen

   Trainiert Kompetenz C1C2

   Lernziel4

5. 5

   Absichern

   ca. 5 Std.

   Du baust Login, Token-Prüfung und Rollen ein und prüfst, dass niemand fremde Daten sehen oder ändern kann.

   • Registrierung mit bcrypt-Hashing und Login mit JWT umsetzen
   • Zwei Rollen definieren und Endpunkte unterschiedlich freigeben
   • Versuchen, mit dem Token von Benutzer A Daten von Benutzer B zu ändern

   Trainiert Kompetenz D1D2D3

   Lernziel5

6. 6

   Tests, Doku und Abschlussprojekt

   ca. 7 Std.

   Du sicherst deine API mit Tests ab, erzeugst die OpenAPI-Doku und baust ein kleines vollständiges Backend wie im Kompetenznachweis.

   • Integrationstests für Erfolg und drei Fehlerfälle schreiben
   • Swagger UI einbinden und Beispiele ergänzen
   • Ein Backend mit zwei bis drei Ressourcen in einem Tag umsetzen und präsentieren

   Trainiert Kompetenz E1E2E3

   Lernziel625

API

Schnittstelle, über die Programme miteinander kommunizieren.

REST

Architekturstil, bei dem Ressourcen über URLs adressiert und mit HTTP-Methoden bearbeitet werden.

Endpunkt

Kombination aus HTTP-Methode und URL, z.B. GET /kunden/42.

DTO

Data Transfer Object: Klasse, die genau die Daten enthält, die über die Schnittstelle gehen.

ORM

Object-Relational Mapping: bildet Datenbanktabellen auf Klassen ab und erzeugt das SQL automatisch.

JWT

JSON Web Token: signiertes Token, das die Identität und Rollen einer angemeldeten Person enthält.

Dependency Injection

Das Framework übergibt einer Klasse ihre Abhängigkeiten, statt dass sie sie selbst erzeugt.

OpenAPI

Standardformat zur Beschreibung von REST-Schnittstellen, aus dem z.B. Swagger UI eine interaktive Doku erzeugt.

Passende Module