Was ist Idempotenz bei HTTP-Methoden?

Idempotency ist eine Eigenschaft von HTTP-Methoden. Eine Anforderung mit einer idempotenten HTTP-Methode kann mehrmals ausgeführt werden, und es wird dasselbe Ergebnis erzeugt. 

Verstehen Sie Ergebnis als Status der Ressource auf dem Server (und beachten Sie, dass Statuscodes aus Sicht der Idempotenz nicht relevant sind).

RFC 7231

Schauen wir uns den RFC 7231 an, das Dokument definiert die Semantik und den Inhalt des HTTP/1.1-Protokolls. Siehe die Zitate unten (Highlights sind meine).

HTTP-Methoden können safe sein:

4.2.1. Sichere Methoden

Request-Methoden gelten als "sicher", wenn ihre definierte Semantik im Wesentlichen schreibgeschützt ist; d. h., der Client fordert keine Zustandsänderung auf dem Origin-Server an und erwartet sie nicht als Ergebnis der Anwendung einer sicheren Methode auf eine Zielressource. [...]

Von den in dieser Spezifikation definierten Anforderungsmethoden sind die Methoden GET, HEAD, OPTIONS und TRACE als sicher definiert. [...]

Und/oder idempotent:

4.2.2. Idempotente Methoden

Eine Anforderungsmethode wird als "idempotent" betrachtet, wenn die beabsichtigte Auswirkung mehrerer identischer Anforderungen mit dieser Methode auf dem Server mit der Auswirkung einer einzelnen solchen Anforderung identisch ist. Von den in dieser Spezifikation definierten Anforderungsmethoden sind PUT, DELETE und sichere Anforderungsmethoden idempotent. [...]

Zusammenfassend werden die HTTP-Methoden als Folgende klassifiziert:

+---------+------+------------+
| Method  | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no   | no         |
| DELETE  | no   | yes        |
| GET     | yes  | yes        |
| HEAD    | yes  | yes        |
| OPTIONS | yes  | yes        |
| POST    | no   | no         |
| PUT     | no   | yes        |
| TRACE   | yes  | yes        |
+---------+------+------------+  

RFC 5789

Der RFC 5789 definiert die PATCH -Methode, die weder sicher noch idempotent ist. Um jedoch Kollisionen zu vermeiden, kann PATCH request so ausgegeben werden, dass es idempotent ist, wie unten angegeben:

Eine PATCH-Anforderung kann so ausgegeben werden, dass sie idempotent ist, was auch dazu beiträgt, schlechte Ergebnisse durch Kollisionen zwischen zwei PATCH-Anforderungen auf derselben Ressource in einem ähnlichen Zeitraum zu verhindern. Kollisionen aus mehreren PATCH-Anforderungen können gefährlicher sein als PUT-Kollisionen, da einige Patch-Formate von einem bekannten Basispunkt aus ausgeführt werden müssen, da sonst die Ressource beschädigt wird. Clients, die diese Art von Patch-Anwendung verwenden, SOLLTEN eine bedingte Anforderung verwenden, sodass die Anforderung fehlschlägt, wenn die Ressource seit dem letzten Zugriff der Clients auf die Ressource aktualisiert wurde. Beispielsweise kann der Client in der ETag-Anforderung eine starke PATCH in einem If-Match-Header verwenden.