Zum Hauptinhalt springen

Einheit 3 — HTTP: Die Sprache der APIs

Was du nach dieser Einheit weißt: Du verstehst wie HTTP-Anfragen aufgebaut sind, was die fünf HTTP-Methoden bedeuten und warum GET und DELETE keine Daten im Body haben.

HTTP ist das Fundament​

REST APIs nutzen HTTP — dasselbe Protokoll das dein Browser verwendet wenn du eine Website aufrufst. Jeder API-Aufruf ist technisch gesehen eine HTTP-Anfrage. Das bedeutet: alles was für HTTP gilt, gilt auch für REST APIs.

Die fünf HTTP-Methoden​

HTTP kennt mehrere Methoden. Für REST APIs sind fünf relevant — und jede hat eine klar definierte semantische Bedeutung:

GET — Daten abrufen​

Liest eine Ressource. Verändert nichts. Der sicherste Aufruf.

GET /customers/42
GET /orders?status=pending&limit=50

Idempotent — beliebig oft wiederholbar, immer dasselbe Ergebnis (solange sich die Daten nicht geändert haben). Kein Request Body.

POST — Neues erstellen​

Erstellt eine neue Ressource. Der Server entscheidet welche ID die neue Ressource bekommt.

POST /orders
Body: { "customer_id": 42, "product_id": 789 }

Nicht idempotent — zweimal derselbe POST erstellt zwei Bestellungen. Bei Netzwerkproblemen und Retry-Logik aufpassen.

PUT — Vollständig ersetzen​

Ersetzt eine Ressource vollständig. Alle Felder müssen mitgeschickt werden. Felder die fehlen werden gelöscht oder auf Standardwert gesetzt.

PUT /customers/42
Body: { "name": "Muster GmbH", "email": "neu@muster.de", "status": "active" }

Idempotent — dasselbe PUT beliebig oft aufrufen, das Ergebnis bleibt gleich.

PATCH — Teilweise aktualisieren​

Aktualisiert nur die mitgeschickten Felder. Alles andere bleibt unverändert.

PATCH /customers/42
Body: { "email": "neu@muster.de" }

Praktischer als PUT wenn man nur ein Feld ändern will. Manche APIs unterstützen nur PUT, manche nur PATCH, manche beide.

DELETE — Löschen​

Löscht eine Ressource.

DELETE /customers/42

Kein Request Body. Idempotent (eine bereits gelöschte Ressource nochmal zu löschen führt zu einer 404-Antwort, aber zu keinem Systemfehler).

Warum GET keinen Body hat​

HTTP definiert, dass GET-Anfragen keine Daten im Body transportieren. Das ist Absicht: GET soll rein lesend sein, und Filter oder Suchparameter gehören in die URL — als Query-Parameter.

GET /orders?status=pending&customer_id=42&from=2026-01-01

Manche Entwickler bauen trotzdem APIs die GET-Anfragen mit Body akzeptieren — das ist technisch möglich aber ein Verstoß gegen die REST-Konventionen und führt zu Kompatibilitätsproblemen.

Der Aufbau einer HTTP-Anfrage​

Jede HTTP-Anfrage besteht aus drei Teilen:

POST /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
Accept: application/json

{
  "customer_id": 42,
  "product_id": 789,
  "quantity": 3
}

Startzeile — Methode, Pfad, HTTP-Version

Header — Metadaten über die Anfrage: wer sendet, welches Format, Authentifizierung, Sprache, ...

Body — die eigentlichen Nutzdaten (nur bei POST, PUT, PATCH)

Die wichtigsten Request-Header​

HeaderBedeutungBeispiel
AuthorizationAuthentifizierungstokenBearer abc123
Content-TypeFormat des Request-Bodyapplication/json
AcceptGewünschtes Antwortformatapplication/json
X-API-KeyAPI-Schlüssel (wenn nicht in Authorization)abc123secret
User-AgentIdentifikation des aufrufenden Systems42OS/1.0

Der Aufbau einer HTTP-Antwort​

HTTP/1.1 201 Created
Content-Type: application/json
Location: /v1/orders/1042

{
  "id": 1042,
  "customer_id": 42,
  "product_id": 789,
  "quantity": 3,
  "status": "pending",
  "created_at": "2026-03-27T10:15:00Z"
}

Status-Zeile — HTTP-Version + Status-Code + Status-Text

Response-Header — Metadaten über die Antwort

Response-Body — die zurückgelieferten Daten (meist JSON)

Idempotenz — warum das wichtig ist​

Idempotent bedeutet: dieselbe Operation beliebig oft ausführen, immer dasselbe Ergebnis.

MethodeIdempotent?Konsequenz
GET✅Problemlos wiederholbar
PUT✅Problemlos wiederholbar
DELETE✅Problemlos wiederholbar (404 nach dem ersten Mal)
POST❌Jeder Aufruf erzeugt eine neue Ressource
PATCHMeistens ✅Abhängig von der Implementierung

In 42°OS-Workflows ist das relevant für die Fehlerbehandlung: Wenn ein GET-Request nach einem Netzwerkfehler wiederholt wird, passiert nichts Schlimmes. Wenn ein POST wiederholt wird, können doppelte Datensätze entstehen. Manche APIs schützen davor mit Idempotency Keys — ein eindeutiger Schlüssel im Header der verhindert dass dieselbe Anfrage zweimal verarbeitet wird.

Weiter: Einheit 4 — Authentifizierung