
Getty Images
Idempotente HTTP-Anfragemethoden und REST
Das Hypertext Transport Protocol verlangt, dass alle HTTP-Verben als idempotent oder nicht-idempotent gekennzeichnet werden. Doch was ist eine idempotente HTTP-Methode?
Das Hypertext Transport Protocol verlangt, dass alle HTTP-Methoden angeben, ob sie idempotent sind oder nicht.
Bei einer idempotenten HTTP-Methode bleiben die Daten auf dem Server nach mehreren Aufrufen immer im gleichen Zustand. Das Löschen eines Newsletter-Abonnements im REST-Format ist eine idempotente Operation, da das Ergebnis mehrerer Anfragen immer dasselbe ist: ein gelöschtes Abonnement.
Damit eine HTTP-Methode in REST idempotent ist, müssen die Daten auf dem Server unabhängig davon, wie oft diese Methode aufgerufen wird, immer im gleichen Zustand bleiben.
Liste idempotenter HTTP-Methoden
Die folgenden idempotenten HTTP-Methoden werden am häufigsten verwendet:
- PUT
- DELETE
- GET
Weniger häufig verwendete idempotente HTTP-Methoden sind:
- HEAD
- OPTIONS
- TRACE
Die HTTP-Verben GET, HEAD, OPTIONS und TRACE werden alle als sichere Operationen kategorisiert, die niemals serverseitige Ressourcen aktualisieren sollten. Eine sichere Operation ist per Definition idempotent.
Nicht-idempotente HTTP-Verben
Die drei häufig verwendeten HTTP-Verben, die nicht-idempotent sind, sind POST, PATCH und CONNECT.
POST wird verwendet, um Daten zu verarbeiten oder Ressourcen zu erstellen, wenn eine Ressourcen-URL unbekannt ist.

PATCH wird verwendet, um eine Ressource basierend auf einer Reihe von Änderungen zu aktualisieren, die in ihrer Nutzlast definiert sind.
CONNECT wird in RESTful APIs selten verwendet. Stattdessen wird einfach HTTP verwendet, um eine Verbindung zu einem Proxy-Server herzustellen und ein VPN zu erstellen.
Beispiele für Idempotenz
Das Konzept der Idempotenz in REST und das Verhalten idempotenter Methoden zur Laufzeit lassen sich am besten anhand von Beispielen erklären.
Wie bereits erwähnt, kann man idempotente Operationen mehrfach aufrufen, aber der Server bleibt immer im gleichen, konsistenten Zustand. Die folgenden Beispiele veranschaulichen dieses Konzept:
- Man weist den Server an, ein Abonnement mehrfach zu löschen. Unabhängig davon, wie oft die Operation ausgeführt wird, wird das Abonnement gelöscht.
- Man weist den Server an, eine Flugstatusressource, die angibt, dass das Flugzeug AC123 pünktlich ist, auf den Server mit PUT abzurufen. Der mehrmalige Aufruf dieser Operation führt immer zum Status pünktlich.
- Man weist den Server an, eine Änderung einer Adresse mit PUT abzurufen. Mehrere Aufrufe führen nicht zu mehreren Adressen. Stattdessen wird bei jedem Aufruf dieselbe Adresse gespeichert.
HTTP-Methode | Sicher | Idempotent |
GET | Ja | Ja |
POST | Nein | Nein |
PUT | Nein | Ja |
PATCH | Nein | Nein |
DELETE | Nein | Ja |
TRACE | Ja | Ja |
HEAD | Ja | Ja |
OPTIONS | Ja | Ja |
CONNECT | Nein | Nein |
PRI | Ja | Ja |
Nicht-idempotente Beispiele
Ein Vorgang ist nicht-idempotent, wenn er bei jedem Aufruf Ressourcen auf dem Server in einem anderen Zustand hinterlässt. Hier sind einige Beispiele für nicht-idempotente RESTful-Operationen:
- Erhöhe das Gehalt aller Mitarbeiter um zehn Prozent.
- Füge einen weiteren Eintrag am Ende einer Protokolldatei hinzu.
- Erhöhe die Anzahl der Veranstaltungsteilnehmer um 100.
Wenn Sie das Gehalt aller Mitarbeiter sieben Mal um zehn Prozent erhöhen, verdoppeln Sie fast das Gehalt aller Mitarbeiter. Bei jeder Ausführung der Operation wird der serverseitigen Ressource ein neuer Wert zugewiesen. Daher ist die Operation definitiv nicht-idempotent.
Idempotentes RESTful-API-Design
Eine der Herausforderungen bei der Entwicklung idempotenter RESTful APIs besteht darin, dass es auf dem Server keinen Mechanismus gibt, um die Sicherheit oder Idempotenz einer Operation zu gewährleisten.
Eine schlecht implementierte GET-Operation kann sowohl unsicher als auch nicht-idempotent sein. Es liegt an den API-Architekten und Softwareentwicklern, zu verstehen, wie RESTful APIs richtig gestaltet werden, damit sie das Konzept der Idempotenz und Sicherheit einhalten.