REST und Web-APIs

HTTP, Ressourcen, Statuscodes und JSON, ohne Framework

Informatik – 3. Semester

Software- und Web-Engineering I · TH Lübeck
Wo wir stehen
Front-EndHTML · CSS · JS/TS · Web Components
⇄
Web-APIHTTP + JSON · heute
⇄
Back-EndSpring Boot · ab nächster Woche
  • Das Front-End kennt ihr: Seiten bauen, gestalten, per fetch() Daten nachladen (web-05)
  • Das Back-End kommt in den nächsten zwei Wochen
  • Dazwischen liegt eine Schnittstelle, über die beide Seiten reden: die Web-API
Die API ist unabhängig davon, womit Front-End und Back-End gebaut sind. Deshalb heute ganz ohne Framework.
Software- und Web-Engineering I · TH Lübeck
Was ist eine Web-API?
API (Application Programming Interface)
Eine festgelegte Schnittstelle, über die ein Programm Daten oder Funktionen eines anderen Programms nutzt. Eine Web-API ist eine solche Schnittstelle, die über HTTP im Netz erreichbar ist.

Server liefert fertiges HTML

  • Browser fordert eine Seite an
  • Server baut das HTML zusammen
  • Jeder Klick lädt eine neue Seite

Server liefert Daten (JSON)

  • JavaScript fragt per fetch() Daten an
  • Server antwortet mit JSON
  • Das Front-End rendert selbst, auch Apps und andere Server können die API nutzen
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Was eigentlich über die Leitung geht.

Software- und Web-Engineering I · TH Lübeck
Request und Response
ClientBrowser, App, anderer Server
→
RequestMethode · URL · Header · Body
→
Server
Client
←
ResponseStatuscode · Header · Body
←
Server
  • Der Client fragt, der Server antwortet: jede Anfrage bekommt genau eine Antwort
  • Zustandslos: Der Server merkt sich zwischen zwei Requests nichts
Folge der Zustandslosigkeit: Jeder Request muss alles mitbringen, was der Server braucht, auch den Nachweis, wer fragt.
Software- und Web-Engineering I · TH Lübeck
Anatomie eines Requests
POST /api/teams/3/tasks HTTP/1.1
Host: taskboard.example.org
Content-Type: application/json
Accept: application/json

{
  "title": "Wireframes abstimmen",
  "dueDate": "2026-12-04"
}
  • Startzeile: Methode, Pfad, HTTP-Version
  • Header: Metadaten als Name: Wert
  • Leerzeile: trennt Header und Body
  • Body: die eigentlichen Daten, optional
HTTP/1.1 ist reiner Text. Was ihr hier seht, geht genau so über die Leitung.
HTTP-Semantik: RFC 9110 · Nachrichtenformat HTTP/1.1: RFC 9112
Software- und Web-Engineering I · TH Lübeck
Anatomie einer Response
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/tasks/17

{
  "id": 17,
  "title": "Wireframes abstimmen",
  "dueDate": "2026-12-04",
  "status": "OPEN",
  "teamId": 3
}
  • Statuszeile: Version, Statuscode, Kurztext
  • Header: hier z.B. die URL der neuen Task
  • Body: die angelegte Task, jetzt mit ID und Status
Der Statuscode ist die wichtigste Zeile: Er sagt dem Client, was passiert ist, bevor er den Body überhaupt liest.
RFC 9110, Abschnitt 15 (Statuscodes) und 10.2.2 (Location)
Software- und Web-Engineering I · TH Lübeck
Header, die ihr kennen solltet
Header Richtung Bedeutung Beispiel
Content-Type beide Format des Bodys application/json
Accept Request gewünschtes Format der Antwort application/json
Authorization Request Nachweis, wer fragt Bearer eyJhbGciOi…
Location Response URL einer neu angelegten Ressource /api/tasks/17
Cache-Control Response ob und wie lange zwischengespeichert werden darf max-age=60
Selbst nachsehen: DevTools öffnen, Tab „Network“, einen Request anklicken, Reiter „Headers“. Dort seht ihr jeden Request, den eine Seite abschickt.
RFC 9110, Abschnitte 8.3 (Content-Type), 12.5.1 (Accept), 11.6.2 (Authorization) · Cache-Control: RFC 9111
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Die API denkt in Dingen, nicht in Aktionen.

Software- und Web-Engineering I · TH Lübeck
REST ist ein Architekturstil
REST (Representational State Transfer)
Ein Architekturstil für verteilte Systeme, beschrieben von Roy Fielding in seiner Dissertation (2000). Kein Protokoll, kein Standard, keine Bibliothek, sondern eine Sammlung von Entwurfsregeln.
  • Client-Server: klare Rollentrennung
  • Zustandslos: jeder Request steht für sich
  • Cachebar: Antworten sagen, ob man sie zwischenspeichern darf
  • Einheitliche Schnittstelle: Ressourcen mit URLs, Standardmethoden, Repräsentationen
  • Schichten: Proxies und Caches dürfen dazwischen liegen
Für eure Projekte zählt vor allem die einheitliche Schnittstelle. Um sie geht es im Rest der Vorlesung.
Fielding, R. T. (2000): Architectural Styles and the Design of Network-based Software Architectures. Dissertation, University of California, Irvine, Kapitel 5
Software- und Web-Engineering I · TH Lübeck
Ressourcen statt Aktionen

So nicht: Aktionen in der URL

GET  /api/getTask?id=17
POST /api/createTask
POST /api/deleteTask?id=17
GET  /api/teams/3/delete

So: Ressourcen und Methoden

GET    /api/tasks/17
POST   /api/teams/3/tasks
DELETE /api/tasks/17
DELETE /api/teams/3
Die URL benennt das Ding (Substantiv). Die HTTP-Methode sagt, was damit passieren soll (Verb).
Software- und Web-Engineering I · TH Lübeck
URLs entwerfen

Pfad: welche Ressource?

  • Substantive im Plural: tasks, teams
  • Sammlung /api/tasks, Element /api/tasks/17
  • Beziehung eine Ebene tief: /api/teams/3/tasks
  • Kleinbuchstaben, Bindestrich: /api/team-members
  • Keine Verben, keine Dateiendungen

Query: welche Auswahl davon?

GET /api/tasks?status=OPEN
GET /api/teams/3/tasks?sort=dueDate
GET /api/tasks?dueBefore=2026-12-18
GET /api/tasks?page=2&size=20

Filtern, Sortieren und Seitenweise-Laden gehören in Query-Parameter, nicht in den Pfad.

Tiefer als eine Ebene wird es unübersichtlich: besser /api/tasks/17 als /api/teams/3/tasks/17.
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Fünf Verben reichen für fast alles.

Software- und Web-Engineering I · TH Lübeck
Die fünf wichtigen Methoden
Methode Zweck Beispiel Request-Body
GET lesen GET /api/tasks/17 nein
POST neu anlegen, Server vergibt die ID POST /api/teams/3/tasks ja
PUT vollständig ersetzen PUT /api/tasks/17 ja
PATCH teilweise ändern PATCH /api/tasks/17 ja
DELETE löschen DELETE /api/tasks/17 nein
CRUD auf HTTP: Create = POST, Read = GET, Update = PUT oder PATCH, Delete = DELETE.
  • Daneben gibt es u.a. HEAD (nur Header) und OPTIONS (was ist erlaubt?), die euch bei CORS begegnen
RFC 9110, Abschnitt 9.3 · PATCH: RFC 5789
Software- und Web-Engineering I · TH Lübeck
Sicher und idempotent
Sicher
Der Request ändert auf dem Server nichts. Er darf beliebig oft gesendet, vorab geladen und zwischengespeichert werden.
Idempotent
Mehrfaches Senden hat dieselbe Wirkung wie einmaliges Senden. Geht die Antwort verloren, darf der Client es gefahrlos wiederholen.
Methode sicher idempotent
GET ja ja
PUT nein ja
DELETE nein ja
POST nein nein
PATCH nein nicht garantiert
Idempotent heißt gleiche Wirkung, nicht gleiche Antwort: Das zweite DELETE /api/tasks/17 liefert 404, die Task ist trotzdem genau einmal weg.
RFC 9110, Abschnitte 9.2.1 (sicher) und 9.2.2 (idempotent) · RFC 5789 (PATCH)
Software- und Web-Engineering I · TH Lübeck
PUT oder PATCH?

PUT ersetzt die ganze Ressource

PUT /api/tasks/17 HTTP/1.1
Content-Type: application/json

{
  "title": "Wireframes abstimmen",
  "dueDate": "2026-12-04",
  "status": "IN_PROGRESS"
}

Was fehlt, ist danach weg.

PATCH ändert nur, was mitkommt

PATCH /api/tasks/17 HTTP/1.1
Content-Type: application/json

{
  "status": "IN_PROGRESS"
}

Alle anderen Felder bleiben, wie sie sind.

Software- und Web-Engineering I · TH Lübeck
Die Task-API auf einen Blick
Methode URL Bedeutung Erfolg
GET /api/teams alle Teams 200
GET /api/teams/3 ein Team lesen 200
POST /api/teams Team anlegen 201 + Location
GET /api/teams/3/tasks?status=OPEN offene Tasks eines Teams 200
POST /api/teams/3/tasks Task anlegen 201 + Location
GET /api/tasks/17 eine Task lesen 200
PUT /api/tasks/17 Task vollständig ersetzen 200
PATCH /api/tasks/17 nur den Status ändern 200
DELETE /api/tasks/17 Task löschen 204
Neun Endpunkte, zwei Ressourcen, keine einzige erfundene Aktion.
Software- und Web-Engineering I · TH Lübeck
Übung: Endpunkte entwerfen

Eine App für Hochschul-Veranstaltungen. Welche Methode und welche URL braucht ihr für:

  1. alle Veranstaltungen im Dezember anzeigen
  2. eine neue Veranstaltung anlegen
  3. die Details einer Veranstaltung abrufen
  4. sich zu einer Veranstaltung anmelden
  5. nur den Raum einer Veranstaltung ändern
  6. die eigene Anmeldung stornieren
5 Min
zu zweit
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Drei Ziffern, die sagen, was passiert ist.

Software- und Web-Engineering I · TH Lübeck
Fünf Klassen, eine Ziffer entscheidet
Erfolg 2xx Hat geklappt. 200, 201, 204
Umleitung 3xx Schau woanders nach. 301, 304
Client-Fehler 4xx Deine Anfrage ist falsch. 400, 401, 403, 404, 409, 422
Server-Fehler 5xx Ich habe ein Problem. 500, 503
Die erste Ziffer sagt, wer handeln muss. Bei 4xx muss der Client die Anfrage ändern. Bei 5xx hilft höchstens, es später noch einmal zu versuchen.
  • 1xx (Zwischenmeldungen) sieht man in APIs praktisch nie
RFC 9110, Abschnitt 15
Software- und Web-Engineering I · TH Lübeck
Die Codes, die ihr wirklich braucht
Code Name Wann?
200 OK Erfolg mit Antwort-Body, z.B. GET
201 Created Ressource angelegt, URL im Location-Header
204 No Content Erfolg ohne Body, z.B. DELETE
400 Bad Request Anfrage kaputt: kein gültiges JSON, falscher Datentyp
401 Unauthorized nicht angemeldet: Wer bist du?
403 Forbidden angemeldet, aber nicht berechtigt
404 Not Found Ressource gibt es nicht
409 Conflict widerspricht dem aktuellen Zustand: Titel im Team schon vergeben
422 Unprocessable Content formal korrekt, fachlich ungültig: Fälligkeit liegt in der Vergangenheit
500 Internal Server Error unerwarteter Fehler auf dem Server
RFC 9110, Abschnitt 15 (422 hieß früher „Unprocessable Entity“)
Software- und Web-Engineering I · TH Lübeck
Übung: Welcher Code passt?
  1. GET /api/tasks/999, diese Task gibt es nicht
  2. POST /api/teams/3/tasks, das Team hat schon eine Task mit diesem Titel
  3. POST /api/teams/3/tasks, der Body ist kein gültiges JSON
  4. DELETE /api/tasks/17, erfolgreich gelöscht
  5. Eine Studentin will ein fremdes Team löschen, darf das aber nicht
  6. Beim Speichern tritt auf dem Server eine unerwartete Exception auf
  7. POST /api/teams, das Team wurde angelegt
3 Min
Handzeichen
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Daten im Body, Fehler mit Ansage.

Software- und Web-Engineering I · TH Lübeck
JSON als Repräsentation
{
  "id": 17,
  "title": "Wireframes abstimmen",
  "dueDate": "2026-12-04",
  "status": "OPEN",
  "teamId": 3,
  "archived": false,
  "labels": ["Entwurf", "UI"],
  "description": null
}
  • Ressource: die Task selbst, egal wie gespeichert
  • Repräsentation: eine Darstellung davon, hier JSON
  • Content-Type: application/json sagt, was im Body steht
  • Konventionen: Feldnamen einheitlich in camelCase, Datum als ISO-8601-String, Listen als Array
JSON kennt nur String, Zahl, Boolean, null, Array und Objekt. Ein Datum gibt es nicht, deshalb schickt man es als String im ISO-Format.
JSON: RFC 8259 · JSON.parse und JSON.stringify aus web-05
Software- und Web-Engineering I · TH Lübeck
Fehler gehören in den Statuscode
So nicht: 200 OK mit { "success": false, "error": "Titel vergeben" }. Jeder Client, jeder Cache und jedes Monitoring hält das für einen Erfolg.
HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
  "type": "/problems/duplicate-title",
  "title": "Titel bereits vergeben",
  "status": 409,
  "detail": "Team 3 hat diesen Titel schon.",
  "instance": "/api/teams/3/tasks"
}

Problem Details (RFC 9457): ein Standardformat für Fehler-Bodys

  • type: Fehlerart als URI
  • title: kurz, für Menschen
  • status: wiederholt den Code
  • detail: dieser konkrete Fall
Nottingham, Wilde, Dalal (2023): RFC 9457, Problem Details for HTTP APIs
Software- und Web-Engineering I · TH Lübeck
Mit fetch eine Task anlegen
const response = await fetch("/api/teams/3/tasks", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Accept": "application/json",
  },
  body: JSON.stringify({
    title: "Wireframes abstimmen",
    dueDate: "2026-12-04",
  }),
});
const task: Task = await response.json();
  • method: Standard wäre GET
  • headers: Body ist JSON
  • body: ein String, also JSON.stringify
  • json(): liest den Body, auch asynchron
MDN: Using the Fetch API, developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
Software- und Web-Engineering I · TH Lübeck
fetch und Fehler
try {
  const res = await fetch("/api/teams/3/tasks", options);
  if (res.ok) {
    renderTask(await res.json());
  } else if (res.status === 409) {
    const problem = await res.json();
    showError(problem.detail);
  } else {
    showError(`Unerwarteter Fehler (${res.status})`);
  }
} catch {
  showError("Server nicht erreichbar");
}
fetch wirft nur bei Netzwerkfehlern. Ein 404 oder 500 ist für fetch eine erfolgreich empfangene Antwort.
  • res.ok ist true bei 200 bis 299
  • Erwartete Fehler gezielt behandeln
  • catch fängt nur: Server weg, kein Netz
MDN: Response.ok und Fetch API, developer.mozilla.org
Software- und Web-Engineering I · TH Lübeck
Die API als Vertrag

Was festgelegt sein muss

  • Methode und URL jedes Endpunkts
  • Aufbau von Request- und Response-Body
  • Statuscodes für Erfolg und für Fehler
  • Fehlerformat, z.B. Problem Details

Wie man ihn festhält

  • Eine Tabelle wie die Task-API reicht für den Anfang
  • Beispiel-JSON zu jedem Endpunkt dazuschreiben
  • OpenAPI: verbreiteter Standard für maschinenlesbare API-Beschreibungen
Tipp für die Umsetzung: Vereinbart die Endpunkte zuerst. Dann kann das Front-End mit Beispiel-JSON arbeiten, bevor das Back-End steht, und später nur die URL tauschen.
Software- und Web-Engineering I · TH Lübeck
1 HTTP-Grundlagen
2 Ressourcen & URLs
3 HTTP-Methoden
4 Statuscodes
5 JSON & Fehlerbehandlung
6 Zusammenfassung

Was ihr aus heute mitnehmt.

Software- und Web-Engineering I · TH Lübeck
Zusammenfassung
  • HTTP: Request aus Methode, URL, Header, Body; Response aus Statuscode, Header, Body; zustandslos
  • Ressourcen: Substantive im Plural, Sammlung /api/tasks und Element /api/tasks/17, Auswahl per Query
  • Methoden: GET lesen, POST anlegen, PUT ersetzen, PATCH ändern, DELETE löschen
  • Eigenschaften: GET ist sicher, GET, PUT und DELETE sind idempotent, POST nicht
  • Statuscodes: 2xx Erfolg, 4xx Fehler des Clients, 5xx Fehler des Servers
  • JSON: Content-Type setzen, Konventionen einheitlich halten
  • Fehler: Statuscode plus Problem Details, im Client immer response.ok prüfen
REST ist kein Framework. Alles von heute gilt unverändert, egal ob das Back-End in Java, TypeScript oder etwas anderem geschrieben ist.
Software- und Web-Engineering I · TH Lübeck
Wie es weitergeht

Die nächsten zwei Wochen

  • Spring Boot, Teil 1: das Framework für die Serverseite
  • Teil 2: Jede Zeile einer API-Tabelle wird zu einer Methode im Controller

Praktikum und Klausur

  • Nach dem Projektwechsel: API des übernommenen Projekts als Tabelle festhalten
  • REST kommt in der Klausur vor: Endpunkte entwerfen, Statuscodes wählen, Methoden einordnen
Zum Üben: Nehmt drei Anforderungen aus dem Katalog eures neuen Projekts und schreibt die passenden Endpunkte auf.
Software- und Web-Engineering I · TH Lübeck

Fragen?

Software- und Web-Engineering I · TH Lübeck

- Neuer Termin, liegt bewusst vor Spring Boot - Heute kein Framework-Code: nur HTTP, JSON und fetch

- Roter Faden: heute die Sprache zwischen den beiden Haelften, naechste Woche die Serverseite - Praktikum: nach dem Projektwechsel baut ihr ein Projekt, das ein anderes Team entworfen hat; die API ist dort der Vertrag

- Beide Varianten sind legitim; rechts ist das, was man heute meist "REST-API" nennt - Anknuepfung web-05: products.json per fetch geladen, das war schon eine (sehr einfache) Web-API

- HTTP kennt ihr aus web-02 als Request/Response-Bild; heute schauen wir in die Nachrichten hinein

- Zustandslos heisst nicht, dass es keine Datenbank gibt; es heisst, dass die Verbindung selbst kein Gedaechtnis hat - Deshalb schickt der Client z.B. ein Token (Zugangsnachweis) bei jedem Request mit

- Laufendes Beispiel fuer heute und beide Spring-Boot-Termine: ein Team-Board mit Aufgaben (Tasks) - Hier: im Team 3 eine neue Task anlegen - Praefix /api trennt die JSON-Schnittstelle von den HTML-Seiten derselben Anwendung - HTTP/2 und HTTP/3 kodieren binaer, die Bestandteile bleiben dieselben

- 201 Created statt 200: es wurde etwas Neues angelegt - ID und Startstatus OPEN vergibt der Server, deshalb stehen sie nur in der Response

- Live zeigen: beliebige Seite, Network-Tab, Filter "Fetch/XHR" - Authorization nur als Begriff; Anmeldung und Tokens kommen mit Spring Security

- Uebergang: HTTP ist das Transportmittel, REST ist die Art, eine API darauf zu entwerfen

- Sechste Regel "Code on Demand" ist optional und fuer uns egal - Im Alltag meint "REST-API" meist: HTTP + JSON + Ressourcen-URLs; das ist nicht ganz Fieldings Definition, aber der uebliche Sprachgebrauch

- Links funktioniert technisch auch, ist aber kein REST: jede API erfindet eigene Verben - GET /api/teams/3/delete ist gefaehrlich: Browser, Crawler und Link-Vorschauen rufen GET-Links ungefragt auf

- Kein Naturgesetz, aber verbreitete Konvention; wichtiger als die Regel ist, dass die API in sich einheitlich ist - Plural auch fuer das Einzelelement: /api/tasks/17, nicht /api/task/17

- Die Substantive haben wir; jetzt die Verben

- CRUD (Create, Read, Update, Delete) kennen sie aus der Datenbank-Welt - CORS (Cross-Origin Resource Sharing) nur erwaehnen; wird relevant, wenn Front-End und Back-End auf verschiedenen Ports laufen

- Praktische Bedeutung: doppelt abgeschicktes Formular per POST legt zwei Tasks an, per PUT nicht - Klausurtypisch: Methode einordnen und die Einordnung begruenden

- Merksatz: PUT schickt die ganze Ressource, PATCH nur die Aenderung - Formal gibt es fuer PATCH eigene Formate (JSON Merge Patch, RFC 7396); im Projekt reicht das obige Muster - Typischer PATCH-Fall: eine Task auf dem Board per Drag-and-drop in die naechste Spalte ziehen

- Diese Tabelle ist das Referenzbeispiel fuer die Klausur und fuer eure eigene API - Die Erfolgscodes schauen wir uns gleich im naechsten Abschnitt an - In Spring Boot Teil 2 implementieren wir davon die fuenf Task-Endpunkte ohne PATCH, Zeile fuer Zeile

- Loesung: 1 GET /events?from=2026-12-01&to=2026-12-31 · 2 POST /events · 3 GET /events/{id} · 4 POST /events/{id}/registrations · 5 PATCH /events/{id} · 6 DELETE /registrations/{id} - Diskussionspunkt 4: "Anmelden" ist keine Aktion, sondern das Anlegen einer Ressource "Anmeldung" - Varianten sammeln; unterschiedliche, aber einheitliche Loesungen sind in Ordnung

- Kleiner Rueckgriff: http.cat aus web-03 war schon ein Statuscode-Bild

- Wer die Klasse kennt, kann auch unbekannte Codes grob einordnen - Das ist die Frage, die ein Client zuerst stellt: muss ich etwas aendern oder nur warten?

- 401 vs. 403 ist der Klassiker: 401 = Identitaet unbekannt, 403 = Identitaet bekannt, Recht fehlt - 400 vs. 422: kaputte Syntax gegen gueltige Syntax mit falschem Inhalt; manche APIs nehmen fuer beides 400, das ist vertretbar - Genau so macht es Spring Boot Teil 2: Validierungsfehler (auch das Datum in der Vergangenheit) werden dort 400

- Loesung: 1 → 404 · 2 → 409 · 3 → 400 · 4 → 204 · 5 → 403 (angemeldet, aber nicht berechtigt) · 6 → 500 · 7 → 201 mit Location - Bei 5 nachfragen: was waere, wenn sie gar nicht angemeldet waere? → 401

- Jetzt der Inhalt der Nachrichten und die Clientseite mit fetch

- Daher der Name: Representational State Transfer, uebertragen wird eine Repraesentation, nicht das Objekt selbst - Dieselbe Ressource koennte auch als HTML oder CSV geliefert werden; der Accept-Header waehlt aus - archived, labels und description zeigen hier nur die JSON-Typen; die Task in Spring Boot Teil 2 ist schlanker (id, title, dueDate, status, teamId)

- Die wichtigste Regel des Abschnitts: der Code traegt die Bedeutung, der Body liefert Details - Eigene Felder sind erlaubt, z.B. eine Liste "errors" mit Feld und Meldung bei 422 - Spring Boot kann dieses Format von Haus aus, das sehen wir naechste Woche

- Das ist exakt der Request von der Anatomie-Folie, nur aus JavaScript heraus - Task ist ein TypeScript-Interface mit id, title, dueDate, status, teamId

- Den response.ok-Check kennt ihr aus web-05; jetzt wisst ihr, warum er noetig ist - Haeufigster Anfaengerfehler: nur try/catch, dann landet ein 409 im Erfolgszweig

- Nach dem Projektwechsel arbeitet ihr auf fremdem Entwurf; eine klar notierte API spart dort am meisten Rueckfragen - Beispiel-JSON als statische Datei, z.B. fetch("/mock/tasks.json"), traegt bis zum echten Back-End - OpenAPI nur nennen, nicht vertiefen

- Kurz zusammenfassen, dann Ausblick auf Spring Boot

- Jede Zeile ist eine moegliche Klausurfrage

- Klausur: REST-Aufgabe mit ca. 4 bis 6 Punkten, Stil wie die beiden Uebungen von heute - Das Team-Board bleibt: Teil 1 nutzt es in der Routing-Uebung, Teil 2 (16.12.) implementiert genau diese Task-API Zeile fuer Zeile

- Zeit fuer Rueckfragen lassen - Falls keine kommen: fragen, welcher Statuscode am meisten verwirrt hat