5.1 HTTP: Anfrage und Antwort

Nach dieser Einheit kannst du:

• den Aufbau von HTTP-Anfragen und -Antworten (Methode, Pfad, Header, Statuscode, Body) und die Zustandslosigkeit des Protokolls erklären.
• die Bedeutung der HTTP-Methoden samt Idempotenz und die wichtigsten Statuscodes mit ihrer Klasseneinteilung nennen und einordnen.
• HTTP-Verkehr mit den DevTools sichtbar machen und mit curl gezielt Anfragen von Hand stellen.

Du tippst in einer Wetter-App auf “Aktualisieren”, und eine halbe Sekunde später steht die neue Temperatur da. Dazwischen ist ein Zettel über das Netz gewandert und ein anderer zurückgekommen, beide in einer Sprache, die jeder Server der Welt versteht.

sequenceDiagram
    accTitle: Eine Wetter-App fragt einen Server
    participant app as Wetter-App (Client)
    participant server as Wetter-Server
    app->>server: GET /forecast?city=Villach
    server-->>app: 200 OK, {"temperature": 18}

Abb. 5.1: Eine Anfrage hin, eine Antwort zurück: so spricht jede App mit ihrem Server (eigene Darstellung).

Wenn zwei Programme über das Netz miteinander sprechen sollen, brauchen sie eine gemeinsame Sprache: ein Protokoll. Das Protokoll des Webs ist HTTP (Hypertext Transfer Protocol), und es transportiert längst nicht mehr nur Webseiten: Apps holen darüber ihre Daten, Server sprechen darüber miteinander, und praktisch jede öffentliche API (Application Programming Interface, eine programmierbare Schnittstelle) ist eine HTTP-Schnittstelle. Der Lehrplan nennt Protokolle und Schnittstellen ausdrücklich; Kapitel 5 legt das Fundament, auf dem du später eigene Schnittstellen entwirfst.

Das Bild für dieses Kapitel kennst du schon: das Lokal aus Kapitel 3. Der Gast gibt dem Kellner einen Bestellzettel, die Küche schickt einen Teller zurück, und auf dem Bon steht, ob alles geklappt hat. Diese Einheit zeigt die Zettel selbst, Einheit 5.2 den Code, der sie schreibt.

Begriffe vorab

• Client und Server: Der Client stellt Anfragen (Browser, App, dein Programm), der Server beantwortet sie.
• Request (Anfrage) und Response (Antwort): die beiden Nachrichten, aus denen jeder HTTP-Austausch besteht.
• Header: Metadaten einer Nachricht als Schlüssel-Wert-Paare, etwa Content-Type: application/json.
• Body: die eigentlichen Daten einer Nachricht, bei APIs fast immer JSON.
• Statuscode: eine dreistellige Zahl in der Antwort, die das Ergebnis meldet, etwa 200 oder 404.
• Idempotent: Eine Anfrage darf gefahrlos wiederholt werden, weil das Ergebnis dasselbe bleibt.

HTTP: Anfrage und Antwort

HTTP ist ein Frage-Antwort-Spiel: Der Client schickt einen Request, der Server antwortet mit einer Response, fertig. Beide Nachrichten sind im Kern lesbarer Text. Eine Anfrage:

GET /api/jobs/42 HTTP/1.1
Host: render.example.org
Accept: application/json

Und die Antwort darauf:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 48

{"id": 42, "state": "running", "progress": 0.62}

Die Bestandteile, die dich das ganze Jahr begleiten:

• Methode (GET): was getan werden soll.
• Pfad (/api/jobs/42): worauf es sich bezieht.
• Header (Accept, Content-Type, …): Metadaten über Anfrage und Antwort.
• Statuscode (200 OK): das Ergebnis in einer Zahl.
• Body: die eigentlichen Daten.

Im Lokal: Die Methode ist “bringen” oder “streichen”, der Pfad das Gericht, die Header sind die Sonderwünsche (“ohne Zwiebel”), und auf dem Bon zurück steht, ob es geklappt hat.

flowchart LR
    accTitle: Die Bestandteile von Request und Response
    req["Request:<br/>Methode + Pfad<br/>Header<br/>Body (optional)"] -- "über das Netz" --> srv["Server"]
    srv -- "über das Netz" --> res["Response:<br/>Statuscode<br/>Header<br/>Body"]

Abb. 5.2: Was in einer Anfrage und in einer Antwort steht (eigene Darstellung).

Wichtig für alles Weitere: HTTP ist zustandslos. Der Server erinnert sich zwischen zwei Anfragen an nichts; jede Anfrage muss alles Nötige mitbringen. Im Lokal wäre das ein Kellner ohne Gedächtnis: Auf jedem Bestellzettel muss die Tischnummer stehen. Was nach einer Einschränkung klingt, ist der Grund, warum das Web skaliert: Jede Anfrage kann von irgendeinem Server beantwortet werden.

Merksatz

HTTP ist zustandslos: Jede Anfrage bringt alles mit, was der Server zum Beantworten braucht.

Konkret heißt das: Bist du in einem Webshop angemeldet, schickt dein Browser bei jeder Anfrage einen Ausweis mit, meist ein Cookie oder ein Token im Header. Der Server erkennt dich nicht wieder, er liest dich jedes Mal neu.

Die Methoden

Methode	Bedeutung	Body?	wiederholbar ohne Schaden?
GET	Daten lesen	nein	ja
POST	etwas Neues anlegen oder eine Aktion auslösen	ja	nein
PUT	Ressource komplett ersetzen	ja	ja
PATCH	Ressource teilweise ändern	ja	meist
DELETE	Ressource löschen	selten	ja

Die letzte Spalte heißt Idempotenz: Ein idempotenter Request darf gefahrlos wiederholt werden, weil das Ergebnis dasselbe bleibt; zweimal dasselbe DELETE löscht nicht mehr als einmal. POST ist die Ausnahme, und genau daraus entstand die Doppelbestellung aus Einheit 4.2. Browser und Werkzeuge verhalten sich entsprechend: GET-Anfragen werden zwischengespeichert und wiederholt, POST nicht.

Wo begegnet dir das? Lädst du eine Seite neu, nachdem du ein Formular abgeschickt hast, fragt der Browser nach, ob er die Daten erneut senden soll. Das ist genau diese Regel: Ein POST wird nicht stillschweigend wiederholt, weil es sonst zweimal bestellt.

Die Statuscodes

Die erste Ziffer sortiert:

Klasse	Bedeutung	wichtige Vertreter
2xx	Erfolg	200 OK, 201 Created, 204 No Content
3xx	Umleitung	301/302 (woanders), 304 Not Modified
4xx	Client-Fehler	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	Server-Fehler	500 Internal Server Error, 503 Service Unavailable

Die Trennlinie zwischen 4xx und 5xx ist die Schuldfrage, und sie entscheidet über die richtige Reaktion: Bei 4xx war die Anfrage falsch, Wiederholen bringt nichts, die Anfrage muss sich ändern. Bei 5xx hat der Server ein Problem, später wiederholen kann helfen. Im Lokal: “Steht nicht auf der Karte” ist ein 404, “die Küche brennt” ein 500.

flowchart LR
    accTitle: Die erste Ziffer entscheidet über die Reaktion
    code{"erste Ziffer?"} -- "2" --> ok["geklappt:<br/>Daten verwenden"]
    code -- "4" --> client["Anfrage falsch:<br/>Anfrage ändern"]
    code -- "5" --> server["Server-Problem:<br/>später wiederholen"]

Abb. 5.3: Wer bei einem Fehler etwas ändern muss, verrät die erste Ziffer des Statuscodes (eigene Darstellung).

Merksatz

4xx heißt: Die Anfrage muss sich ändern. 5xx heißt: Der Server hat ein Problem, später versuchen kann helfen.

Die Merkhilfe der Zunft

Unter Entwicklerinnen und Entwicklern kursiert eine grobe, aber treffsichere Kurzfassung der vier Klassen: 2xx – it worked (“hat geklappt”), 3xx – it moved (“liegt woanders, ich sag dir wo”), 4xx – you fucked up (“du hast Mist gebaut”) und 5xx – we fucked up (“wir haben Mist gebaut”). Nicht zitierfähig fürs Maturaprotokoll, aber die Schuldfrage bei 4xx gegen 5xx merkt man sich damit für immer.

Kurz nachgedacht

Welcher Statuscode passt, und wer muss etwas ändern? (a) Die URL hat einen Tippfehler. (b) Die Datenbank des Servers ist ausgefallen. (c) Du rufst eine Seite auf, für die man angemeldet sein muss, bist es aber nicht. (d) Ein neuer Benutzer wurde erfolgreich angelegt.

Auflösung

(a) 404 Not Found: Die Anfrage muss sich ändern. (b) 500 Internal Server Error oder 503 Service Unavailable: Der Server muss das Problem beheben, die Anfrage war in Ordnung. (c) 401 Unauthorized: Du musst dich anmelden, also die Anfrage um den Ausweis ergänzen. (d) 201 Created: Alles hat geklappt, etwas Neues ist entstanden.

Das Protokoll sichtbar machen

HTTP versteht am schnellsten, wer es beobachtet. Zwei Werkzeuge dafür:

Der Netzwerk-Tab der Browser-DevTools (F12) zeigt jede Anfrage der aktuellen Seite: Methode, URL, Status, Dauer, sämtliche Header und den Body. Öffne eine beliebige Webseite mit offenem Netzwerk-Tab: Dutzende Anfragen für Seiten, Bilder, Skripte und Daten, jede einzeln anklickbar. Dieser Tab ist für den Rest des Jahres dein wichtigstes Diagnosewerkzeug.

curl stellt Anfragen direkt aus dem Terminal, ohne jeden Code. Zum Ausprobieren eignet sich der öffentliche Testdienst httpbin.org, der jede Anfrage einfach zurückschickt. Das komfortablere HTTPie (http) kannst du zusätzlich installieren.

curl -i https://httpbin.org/get                 # -i: show response headers
curl -X POST https://httpbin.org/post \
     -H "Content-Type: application/json" \
     -d '{"filename": "intro.mp4"}'

http GET https://httpbin.org/get                # HTTPie: same, friendlier

curl ist unter Windows 11 bereits installiert, unter macOS und Linux üblicherweise ebenso. In der alten Windows PowerShell 5.1 ist curl allerdings nur ein Kürzel für den Befehl Invoke-WebRequest, der ganz andere Optionen hat; dort tippst du curl.exe. In PowerShell 7 und in der Git Bash gilt curl wie oben.

Unter Linux und macOS findest du oft auch wget, das eigentlich zum Herunterladen von Dateien gedacht ist, sich aber genauso zum schnellen Antippen einer API eignet:

wget -qO- https://httpbin.org/get               # -q: quiet, -O-: body to stdout
wget -S --spider https://httpbin.org/get        # inspect the response headers only

Unter Windows ist wget nicht installiert, und in Windows PowerShell 5.1 ist wget wie curl nur ein Kürzel für Invoke-WebRequest. Faustregel: curl zum Ausprobieren und Fehlersuchen (feine Kontrolle über Methode, Header, Body), wget wenn es ums bloße Herunterladen geht.

flowchart LR
    accTitle: Verschiedene Werkzeuge, dasselbe Protokoll
    dev["DevTools:<br/>zusehen"] --> http(("HTTP"))
    curl["curl / HTTPie:<br/>von Hand fragen"] --> http
    code["fetch im Code:<br/>Einheit 5.2"] --> http
    http --> server["Server"]

Abb. 5.4: Ob Browser, Terminal oder eigener Code: Alle sprechen dasselbe HTTP mit dem Server (eigene Darstellung).

Anfragen aus dem Terminal sind das schnellste Mittel, eine API auszuprobieren oder einen Fehler einzugrenzen (“Liegt es an meinem Code oder an der API?”), und sie bleiben es auch, wenn du ab Kapitel 9 deine eigene API testest.

Wo begegnet dir das? Bei jeder Fehlersuche in einer Web-App: Zeigt die Seite “Fehler beim Laden”, verrät der Netzwerk-Tab in Sekunden, ob die Anfrage mit 404, 500 oder gar nicht beantwortet wurde, und damit, wo du weitersuchen musst.

Kurz nachgedacht

curl -i https://httpbin.org/status/404: Was steht in der ersten Zeile der Antwort, und muss jemand den Server reparieren?

Auflösung

Die erste Zeile lautet HTTP/1.1 404 NOT FOUND (httpbin schreibt den Text in Großbuchstaben). Niemand muss den Server reparieren: Ein 4xx meldet, dass die Anfrage nicht passt; hier ist das sogar Absicht, denn /status/404 liefert genau diesen Code zum Üben.

Stolperfallen

1. 4xx und 5xx verwechselt: Bei 4xx hilft kein Wiederholen, die Anfrage muss sich ändern; bei 5xx liegt das Problem beim Server.
2. POST automatisch wiederholt: POST ist nicht idempotent; ein zweiter Versuch legt womöglich ein zweites Objekt an.
3. curl in Windows PowerShell 5.1: Dort ist curl ein Kürzel für Invoke-WebRequest, Optionen wie -i oder -X scheitern. curl.exe tippen.
4. Zustand am Server erwartet: Der Server erinnert sich nicht an die vorige Anfrage. Was er braucht, muss in jeder Anfrage stehen.

Zusatzmaterialien

• MDN: An overview of HTTP - Aufbau von Nachrichten, Zustandslosigkeit und die Rolle von Headern.
• MDN: HTTP response status codes - alle Statuscodes mit Erklärung.
• MDN: HTTP request methods - Methoden, sichere und idempotente Methoden.
• httpbin.org - ein Testdienst, der Anfragen zurückschickt und jeden Statuscode liefern kann; ideal zum Ausprobieren mit curl.
• Everything curl - das freie Buch zu curl, vom Autor des Werkzeugs.

Zum Anhören

Du kannst dir diese Einheit kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen (etwa „Laut vorlesen” in Edge), ohne Konto und ohne Upload; die Befehle liest du dabei am Bildschirm mit. Freiwillig kannst du mit Google NotebookLM (Google-Konto nötig) aus diesem öffentlichen Text eine gesprochene Zusammenfassung erzeugen, auch auf Deutsch.

Lernergebnisse

Du kannst jetzt:

• den Aufbau von HTTP-Anfragen und -Antworten (Methode, Pfad, Header, Statuscode, Body) und die Zustandslosigkeit des Protokolls erklären.
• die Bedeutung der HTTP-Methoden samt Idempotenz und die wichtigsten Statuscodes mit ihrer Klasseneinteilung nennen und einordnen.
• HTTP-Verkehr mit den DevTools sichtbar machen und mit curl gezielt Anfragen von Hand stellen.

Passende Übungen

• Aufgabe 05-1a - API-Konsument, Stufe Wesentlich_überwiegend (HTTP beobachten, von Hand anfragen)

Quellen

• Aufbau von HTTP-Nachrichten, Zustandslosigkeit → MDN: An overview of HTTP
• Methoden, Idempotenz → MDN: HTTP request methods, Idempotent
• Statuscodes und ihre Klassen → MDN: HTTP response status codes
• curl, Optionen -i, -X, -H, -d → Everything curl
• curl in Windows 11 vorinstalliert, in Windows PowerShell 5.1 sind curl und wget Kürzel für Invoke-WebRequest, kein wget unter Windows → eigener Test unter Windows 11 mit Windows PowerShell 5.1 und PowerShell 7.6 (Oktober 2026)
• Antworten von httpbin.org (/get, /post, /status/404) → eigener Test mit curl 8.11 (Oktober 2026)
• Lehrplanbezug (Protokolle, Schnittstellen) → Lehrplan der Höheren Lehranstalt für Informationstechnologie, B.2 Medientechnik, 2.1 Softwareentwicklung, IV. Jahrgang (zitiert auf der Kursseite Lehrplan und Ablauf)
• Abb. 5.1 (Wetter-App), Abb. 5.2 (Request und Response), Abb. 5.3 (Statuscode-Klassen), Abb. 5.4 (Werkzeuge) → eigene Darstellung, alle als Mermaid-Diagramm

Autoren

• Oliver Maurhart (MAO)
• Michael Gabriel (GAM)

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules