2.2. Fehlerbehandlung
2.2. Fehlerbehandlung
Es gibt mehrere bekannte Bedingungen, unter denen eine PATCH-Anfrage fehlschlagen kann.
Fehlerhaftes Patch-Dokument (Malformed patch document): Wenn der Server feststellt, dass das vom Client bereitgestellte Patch-Dokument nicht ordnungsgemäß formatiert ist, SOLLTE (SHOULD) er eine 400 (Bad Request)-Antwort zurückgeben. Die Definition von fehlerhaft formatiert hängt vom gewählten Patch-Dokument ab.
Nicht unterstütztes Patch-Dokument (Unsupported patch document): Kann mit einer 415 (Unsupported Media Type)-Antwort angegeben werden, wenn der Client ein Patch-Dokumentformat sendet, das der Server für die durch den Request-URI identifizierte Ressource nicht unterstützt. Eine solche Antwort SOLLTE (SHOULD) einen Accept-Patch-Antwort-Header enthalten, wie in Abschnitt 3.1 beschrieben, um den Client über die unterstützten Patch-Dokument-Medientypen zu informieren.
Nicht verarbeitbare Anfrage (Unprocessable request): Kann mit einer 422 (Unprocessable Entity)-Antwort ([RFC4918], Abschnitt 11.2) angegeben werden, wenn der Server das Patch-Dokument versteht und die Syntax des Patch-Dokuments gültig zu sein scheint, der Server jedoch nicht in der Lage ist, die Anfrage zu verarbeiten. Dies könnte Versuche umfassen, eine Ressource auf eine Weise zu ändern, die dazu führen würde, dass die Ressource ungültig wird; zum Beispiel eine Änderung an einem wohlgeformten XML-Dokument, die dazu führen würde, dass es nicht mehr wohlgeformt ist. Es kann auch spezifischere Fehler geben wie "Konfliktstatus (Conflicting State)", wie oben erwähnt. In solchen Fällen KANN (MAY) der Server Fehlerinformationen im Antwortkörper einschließen, damit der Benutzer bestimmen kann, was mit der Patch-Anfrage nicht stimmt.
Ressource nicht gefunden (Resource not found): Wenn die Ressource, auf die der Client versucht, den Patch anzuwenden, nicht existiert und der Server das Erstellen neuer Ressourcen mit PATCH nicht unterstützt, gibt der Server einen 404 (Not Found)-Statuscode zurück.
Konfliktstatus (Conflicting state): Wenn die Anfrage ordnungsgemäß formatiert ist und der Server den im Patch-Dokument verwendeten Medientyp unterstützt, der Server den Patch jedoch nicht anwenden kann, weil der Status der Ressource mit dem Patch in Konflikt steht oder der Patch einen Konflikt erzeugen wird (z. B. ein Patch, der versucht, ein konfliktierendes Feld hinzuzufügen, oder eine bedingte Anfrage, die fehlschlägt), gibt der Server einen 409 (Conflict)-Statuscode zurück. Der Server SOLLTE (SHOULD) genügend Informationen im Antwortkörper einschließen, damit der Client die Quelle des Konflikts erkennen kann.
Konfliktierende Änderung (Conflicting modification): Wenn die Anfrage ordnungsgemäß formatiert ist und der Server den Medientyp unterstützt, der Patch jedoch nicht auf die Ressource angewendet werden kann, weil sich die Ressource vom erwarteten Zustand geändert hat (z. B. die bedingte Anfrage fehlgeschlagen ist, ein starker ETag nicht mit der aktuellen Ressource übereinstimmt), gibt der Server einen 412 (Precondition Failed)-Statuscode zurück.
Gleichzeitige Änderung (Concurrent modification): Gleichzeitige Anfragen zum Ändern einer Ressource mit PATCH können unvorhersehbare Ergebnisse haben, wenn die verwendeten Patch-Formate erfordern, dass der Client von einem zugrunde liegenden Basisdokument (base document) aus arbeitet. Somit kann eine PATCH-Anfrage fehlschlagen, wenn gleichzeitige Aktualisierungen einen Konflikt verursachen. Alle solchen Risiken gleichzeitiger Änderungen gelten für jede Interaktion, bei der mehrere Parteien Änderungen an derselben Ressource vornehmen. Die PATCH-Methode führt keine einzigartigen Risiken ein, ist aber in diesem Abschnitt hervorzuheben.
Hinweis: Für alle Antworten kann der Server Fehlerinformationen im Antwortkörper einschließen, damit der Client bestimmen kann, was schief gelaufen ist oder was als nächstes zu tun ist.