Eine HTTP-Methode ist idempotent, wenn eine identische Anforderung einmal oder mehrmals hintereinander mit demselben Effekt ausgeführt werden kann, während der Server im selben Zustand bleibt. Mit anderen Worten, eine idempotente Methode sollte keine Nebenwirkungen haben (außer zum Führen von Statistiken). Korrekt implementiert sind die Methoden GETHEADPUT und DELETE idempotent, nicht jedoch die Methode POST. Alle sicheren Methoden sind auch idempotent.

Um idempotent zu sein, wird nur der tatsächliche Back-End-Status des Servers berücksichtigt, der von jeder Anforderung zurückgegebene Statuscode kann sich unterscheiden: Der erste Aufruf von a DELETE wird wahrscheinlich a 200 , während aufeinanderfolgende wahrscheinlich a 404 . Eine weitere Implikation von DELETE idempotent ist, dass Entwickler keine RESTful-APIs mit einer delete last Entry-Funktionalität mit der DELETE -Methode implementieren sollten.

Beachten Sie, dass die Idempotenz einer Methode vom Server nicht garantiert wird und einige Anwendungen die Idempotenzeinschränkung möglicherweise fälschlicherweise unterbrechen.

GET /pageX HTTP/1.1 ist idempotent. Wenn der Client mehrmals hintereinander aufgerufen wird, erhält er die gleichen Ergebnisse:

GET /pageX HTTP/1.1GET /pageX HTTP/1.1GET /pageX HTTP/1.1GET /pageX HTTP/1.1

POST /add_row HTTP/1.1 ist nicht idempotent; Wenn er mehrmals aufgerufen wird, fügt er mehrere Zeilen hinzu:

POST /add_row HTTP/1.1POST /add_row HTTP/1.1 -> Adds a 2nd rowPOST /add_row HTTP/1.1 -> Adds a 3rd row

DELETE /idX/delete HTTP/1.1 ist idempotent, auch wenn sich der zurückgegebene Statuscode zwischen den Anforderungen ändern kann:

DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX existsDELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deletedDELETE /idX/delete HTTP/1.1 -> Returns 404