Warum ist die PATCH-Methode nicht idempotent?

Ich habe mich darüber gewundert.

Angenommen, ich habe eine userRessource mit idund nameFeldern. Wenn ich ein Feld aktualisieren möchte, könnte ich einfach eine PATCH-Anfrage an die Ressource wie folgt senden

PATCH /users/42
{"name": "john doe"} 

Anschließend aktualisiert die Anwendung den Namen des Benutzers 42.

Aber warum ist das Ergebnis anders, wenn ich diese Aufforderung wiederhole?

Gemäß RFC 5789

PATCH ist weder sicher noch idempotent

Eine PATCH-Anfrage kann idempotent sein, muss es aber nicht. Das ist der Grund, warum es als nicht idempotent charakterisiert wird.

Ob PATCH idempotent sein kann oder nicht, hängt stark davon ab, wie die erforderlichen Änderungen kommuniziert werden.
Wenn das Patch-Format beispielsweise die Form von hat {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, hat jede PATCH-Anforderung nach der ersten eine andere Auswirkung (eine Fehlerantwort) als die erste Anforderung.
Ein weiterer Grund für Nicht-Idempotenz kann sein, dass das Anwenden der Änderung auf etwas anderes als die ursprüngliche Ressource die Ressource ungültig machen kann. Dies wäre dann auch der Fall, wenn Sie die Änderung mehrfach anwenden.

Ich denke, klare Antwort, wenn PATCH nicht idempotent ist dieser Absatz aus RFC 5789:

Es gibt auch Fälle, in denen Patch-Formate nicht von einem bekannten Ausgangspunkt aus ausgeführt werden müssen (z. B. Anhängen von Textzeilen an Protokolldateien oder nicht kollidierende Zeilen an Datenbanktabellen). In diesem Fall ist die gleiche Sorgfalt bei Client-Anforderungen nicht erforderlich .

Da RFC angibt, dass der Patch einige "allgemeine Änderungen" an der Ressource enthält, sollten wir uns nicht nur mit dem Ersetzen von Feldern befassen. Wenn es sich bei der Ressource um einen Zähler handelt, kann der Patch das Inkrement anfordern, was eindeutig nicht idempotet ist.

PATCHAnforderungen beschreiben eine Gruppe von Vorgängen, die auf eine Ressource angewendet werden sollen. Wenn Sie dieselbe Gruppe von Vorgängen zweimal auf dieselbe Ressource anwenden, ist das Ergebnis möglicherweise nicht dasselbe. Dies liegt daran, dass Sie die Operationen selbst definieren können. Mit anderen Worten, Sie müssen die Zusammenführungsregeln definieren .

Denken Sie daran, dass eine PATCHAnfrage zum Patchen von Ressourcen in vielen verschiedenen Formaten verwendet werden kann, nicht nur für JSON.

Eine PATCHAnfrage kann also idempotent sein, wenn Sie die Zusammenführungsregeln als idempotent definieren .

Idempotentes Beispiel:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  age: 33
}

// New resource
{
  name: 'Tito',
  age: 33
}

Nicht idempotentes Beispiel:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  $increment: 'age'
}

// New resource
{
  name: 'Tito',
  age: 33
}

Im zweiten Beispiel habe ich eine "Mongo-ähnliche" Syntax verwendet, die ich für das Inkrementieren eines Attributs erfunden habe. Dies ist eindeutig nicht idempotent, da das mehrmalige Senden derselben Anfrage jedes Mal zu unterschiedlichen Ergebnissen führen würde.

Jetzt fragen Sie sich vielleicht, ob die Verwendung einer solchen Syntax gültig ist. Nach Standards ist es:

Der Unterschied zwischen den Anforderungen PUT und PATCH spiegelt sich in der Art und Weise wider, wie der Server die eingeschlossene Entität verarbeitet, um die durch den Anforderungs-URI angegebene Ressource zu ändern. In einer PUT-Anforderung wird die eingeschlossene Entität als geänderte Version der auf dem Ursprungsserver gespeicherten Ressource betrachtet, und der Client fordert das Ersetzen der gespeicherten Version an. Mit PATCH enthält die beigefügte Entität jedoch eine Reihe von Anweisungen, die beschreiben, wie eine Ressource, die sich derzeit auf dem Ursprungsserver befindet, geändert werden sollte, um eine neue Version zu erstellen.

Und vielleicht fragen Sie sich auch, ob es sich lohnt , PATCHAnfragen auf diese Weise zu verwenden, und viele Leute sind der Meinung , dass dies nicht der Fall ist. Hier finden Sie eine gute Antwort mit vielen Kommentaren zu diesem Problem.