PATCH

Die PATCH HTTP-Methode wendet partielle Änderungen auf eine Ressource an.

PATCH ist in gewissem Maße mit dem "Update"-Konzept in CRUD vergleichbar (im Allgemeinen ist HTTP anders als CRUD und beide sollten nicht verwechselt werden).

Im Vergleich zu PUT dient ein PATCH als eine Reihe von Anweisungen zur Änderung einer Ressource, während PUT einen vollständigen Ersatz der Ressource darstellt. Eine PUT-Anfrage ist immer idempotent (das wiederholte Senden derselben Anfrage führt dazu, dass die Ressource im gleichen Zustand bleibt), während eine PATCH-Anfrage nicht immer idempotent sein muss. Wenn eine Ressource beispielsweise einen sich automatisch erhöhenden Zähler enthält, wird eine PUT-Anfrage den Zähler überschreiben (da sie die gesamte Ressource ersetzt), aber eine PATCH-Anfrage möglicherweise nicht.

Ähnlich wie POST kann eine PATCH-Anfrage potenziell Auswirkungen auf andere Ressourcen haben.

Ein Server kann die Unterstützung für PATCH anzeigen, indem er es zur Liste in den Allow oder Access-Control-Allow-Methods (für CORS) Antwortheadern hinzufügt. Ein weiteres implizites Zeichen dafür, dass PATCH unterstützt wird, ist der Accept-Patch Header (normalerweise nach einer OPTIONS-Anfrage zu einer Ressource), der die Medientypen auflistet, die der Server in einer PATCH-Anfrage für eine Ressource verstehen kann.

Anfrage hat einen Körper Ja
Erfolgreiche Antwort hat einen Körper Könnte
Sicher Nein
Idempotent Nein
Cacheable Nur wenn Frischeinformationen enthalten sind
In HTML-Formularen erlaubt Nein

Syntax

http
PATCH <request-target>["?"<query>] HTTP/1.1
<request-target>

Identifiziert die Zielressource der Anfrage in Verbindung mit den Informationen, die im Host Header bereitgestellt werden. Dies ist ein absoluter Pfad (z.B. /path/to/file.html) in Anfragen an einen Ursprungsserver und eine absolute URL in Anfragen an Proxys (z.B. http://www.example.com/path/to/file.html).

<query> Optional

Eine optionale Abfragekomponente, die von einem Fragezeichen ? eingeleitet wird. Wird oft verwendet, um identifizierende Informationen in der Form von key=value Paaren zu übermitteln.

Beispiele

Erfolgreiches Modifizieren einer Ressource

Angenommen, es gibt eine Ressource auf dem Server, die einen Benutzer mit einer numerischen ID von 123 im folgenden Format darstellt:

json
{
  "firstName": "Example",
  "LastName": "User",
  "userId": 123,
  "signupDate": "2024-09-09T21:48:58Z",
  "status": "active",
  "registeredDevice": {
    "id": 1,
    "name": "personal",
    "manufacturer": {
      "name": "Hardware corp"
    }
  }
}

Anstatt ein JSON-Objekt zu senden, um eine Ressource vollständig zu überschreiben, modifiziert ein PATCH nur spezifische Teile der Ressource. Diese Anfrage aktualisiert das status-Feld:

http
PATCH /users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 27
Authorization: Bearer ABC123

{
  "status": "suspended"
}

Die Interpretation und Authentifizierung der PATCH-Anfrage hängen von der Implementierung ab. Erfolg kann durch einen beliebigen der erfolgreichen Antwortstatuscodes angezeigt werden. In diesem Beispiel wird ein 204 No Content verwendet, da es nicht notwendig ist, einen Körper mit zusätzlichen Informationen zur Operation zu übermitteln. Ein ETag wird bereitgestellt, damit der Anrufer eine bedingte Anfrage in der Zukunft durchführen kann:

http
HTTP/1.1 204 No Content
Content-Location: /users/123
ETag: "e0023aa4f"

Spezifikationen

Specification
RFC 5789

Siehe auch