Angenommen, ich möchte eine Art optimistisches Sperren implementieren und ETags verwenden, um den aktuellsten Ressourcenstatus anzugeben. Das bedeutet, Clients verwenden einen Header If-Match , wenn PUT für ein Update gilt.
Laut der HTTP-Spezifikation muss der Server% co_de zurückgeben %, wenn der für den Header 412 Precondition failed angegebene ETag nicht mit dem aktuellen Status der Ressource übereinstimmt.
If-Match scheint jedoch näher an dem zu liegen, was ich möchte semantisch auszudrücken, vor allem, da es Richtlinien gibt, was in die Antwort einbezogen werden soll.
Ist es schrecklich falsch, 409 Conflict zurückzugeben, falls ein ETag, das in einem 409 Header bereitgestellt wird, nicht übereinstimmt?
Von Ihrem Link zur Spezifikation:
Wenn keine der Entity-Tags übereinstimmt oder wenn "*" angegeben ist und keine aktuelle Entität vorhanden ist, MUSS der Server die angeforderte Methode NICHT ausführen und MUSS eine 412-Antwort (Vorbedingung fehlgeschlagen) zurückgeben. Dieses Verhalten ist am nützlichsten, wenn der Client verhindern möchte, dass eine Aktualisierungsmethode wie PUT eine Ressource ändert, die sich geändert hat, seit der Client sie zuletzt abgerufen hat.
Da die Spezifikation ein HTTP 412 erfordert (tatsächlich verwendet sie "MUST"), und weil es klar ist, dass sie genau den Anwendungsfall berücksichtigten, der diskutiert wird, scheint ein HTTP 412 wie der richtige Antwortcode zu sein.
412 ist sowieso ziemlich vernünftig. Die Anforderung besagt, das Update bedingt durchzuführen. Die 412 sagt, dass die Bedingung fehlgeschlagen ist, also wird der Dienst es nicht tun. Zumal 412 gut zu dem Konzept bedingter Anfragen passt; 409 scheint auf eine bestimmte Art von Ablehnung zu beruhen, die bedingt sein kann oder nicht. Zum Beispiel könnte ich einen Dienst sehen, der eine 409 als Antwort auf eine unbedingte Anforderung zurückgibt, etwas mit einem internen Konflikt zu POST zu senden.
Aber sehen Sie Folgendes, auch aus der Spezifikation:
10.4.10 409 Konflikt
Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht abgeschlossen werden. Dieser Code ist nur in Situationen zulässig, in denen der Benutzer möglicherweise den Konflikt lösen und die Anforderung erneut senden kann. Die Antwortstelle SOLLTE ausreichend Informationen enthalten, damit der Benutzer die Konfliktquelle erkennen kann. Im Idealfall würde die Antworteinheit genügend Informationen für den Benutzer oder Benutzeragenten enthalten, um das Problem zu beheben. Dies ist jedoch möglicherweise nicht möglich und wird nicht benötigt.
Konflikte treten am wahrscheinlichsten als Antwort auf eine PUT-Anfrage auf. Wenn beispielsweise die Versionierung verwendet wird und die Entität, die PUT enthält, Änderungen an einer Ressource enthält, die mit denen einer früheren (Drittanbieter-) Anforderung in Konflikt stehen, verwendet der Server möglicherweise die 409-Antwort, um anzugeben, dass die Anforderung nicht abgeschlossen werden kann . In diesem Fall würde die Antworteinheit wahrscheinlich eine Liste der Unterschiede zwischen den beiden Versionen in einem Format enthalten, das durch die Antwort Content-Type definiert ist.
Wie auch immer, die Spezifikation scheint in konditionalen Anforderungskontexten 412 zu erfordern, während sie vorschlägt, dass Versionskonflikte ein Schlüsseltreiber für 409s sind. Es könnte sein, dass die 409 verwendet wird, wenn der Versionskonflikt als Teil einer unbedingten Anforderung auftritt.
Tags und Links rest http web optimistic-locking