HTTP-Methoden

Die GET-Methode fordert eine Darstellung der angegebenen Ressource an. GET-Anfragen sollten ausschliesslich Daten abrufen und keine weiteren Auswirkungen auf die Ressource haben. Da GET-Anfragen den Zustand nicht veraendern, gelten sie als sicher und idempotent.

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "admin",
  "createdAt": "2025-08-14T10:30:00Z"
}

Die POST-Methode sendet eine Entitaet an die angegebene Ressource und verursacht haeufig eine Zustandsaenderung oder Nebeneffekte auf dem Server. Sie wird ueblicherweise verwendet, um neue Ressourcen zu erstellen oder Operationen auszuloesen. POST ist weder sicher noch idempotent, was bedeutet, dass wiederholte identische Anfragen doppelte Ressourcen erzeugen koennen.

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "name": "Bob Smith",
  "email": "bob@example.com",
  "role": "member"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/456

{
  "id": 456,
  "name": "Bob Smith",
  "email": "bob@example.com",
  "role": "member",
  "createdAt": "2026-03-02T14:22:00Z"
}

Die PUT-Methode ersetzt alle aktuellen Darstellungen der Zielressource durch den Anfrage-Payload. Falls die Ressource nicht existiert, kann PUT sie erstellen. PUT ist idempotent, was bedeutet, dass dieselbe Anfrage mehrmals gestellt das gleiche Ergebnis liefert wie eine einmalige Anfrage.

PUT /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "name": "Alice Johnson-Smith",
  "email": "alice.js@example.com",
  "role": "admin"
}

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

{
  "id": 123,
  "name": "Alice Johnson-Smith",
  "email": "alice.js@example.com",
  "role": "admin",
  "updatedAt": "2026-03-02T15:10:00Z"
}

Die PATCH-Methode wendet teilweise Aenderungen auf eine Ressource an. Im Gegensatz zu PUT, das die gesamte Ressource ersetzt, aktualisiert PATCH nur die im Anfragekörper angegebenen Felder. PATCH ist weder sicher noch zwingend idempotent, kann aber idempotent implementiert werden.

PATCH /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
  "email": "alice.new@example.com"
}

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

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice.new@example.com",
  "role": "admin",
  "updatedAt": "2026-03-02T15:45:00Z"
}

Die DELETE-Methode entfernt die angegebene Ressource vom Server. Nach einem erfolgreichen DELETE sollten nachfolgende GET-Anfragen an dieselbe URI den Status 404 Not Found zurueckgeben. DELETE ist idempotent, was bedeutet, dass das Loeschen einer bereits geloeschten Ressource ueber die erstmalige Entfernung hinaus keinen Fehler erzeugen sollte.

DELETE /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

HTTP/1.1 204 No Content
X-Request-Id: req_abc123

Die HEAD-Methode ist identisch mit GET, mit der Ausnahme, dass der Server keinen Nachrichtenkoerper in der Antwort zurueckgeben darf. Sie ist nuetzlich, um zu pruefen, ob eine Ressource existiert, Header zu inspizieren oder Links zu testen, ohne die gesamte Antwort herunterzuladen. HEAD ist sicher und idempotent.

HEAD /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Die OPTIONS-Methode beschreibt die verfuegbaren Kommunikationsoptionen fuer die Zielressource. Sie wird haeufig bei CORS-Preflight-Anfragen verwendet, bei denen der Browser prueft, welche HTTP-Methoden und Header erlaubt sind, bevor die eigentliche Anfrage gesendet wird. OPTIONS ist sicher und idempotent.

OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

Die TRACE-Methode fuehrt einen Nachrichten-Loopback-Test entlang des Pfades zur Zielressource durch und gibt die empfangene Anfrage zurueck. Sie wird hauptsaechlich zu Diagnosezwecken verwendet, um zu sehen, wie zwischengeschaltete Proxys die Anfrage veraendern. TRACE wird in Produktions-APIs selten verwendet und ist aus Sicherheitsgruenden oft deaktiviert.

TRACE /api/users HTTP/1.1
Host: api.example.com
Max-Forwards: 3

Die CONNECT-Methode stellt einen Tunnel zum durch die Zielressource identifizierten Server her. Sie wird hauptsaechlich mit HTTP-Proxys verwendet, um eine End-to-End-TLS/SSL-Verbindung durch den Proxy aufzubauen, sodass HTTPS-Verkehr durch einen HTTP-Proxy geleitet werden kann. CONNECT ist weder sicher noch cachefaehig.

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz