PATCH request method
Die PATCH
HTTP-Methode wendet teilweise Änderungen an einer Ressource an.
PATCH
ist in gewisser Weise analog zum "Update"-Konzept, das im CRUD vorkommt (im Allgemeinen ist HTTP anders als CRUD und die beiden 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 verbleibt), während eine PATCH
-Anfrage nicht immer idempotent ist.
Beispielsweise, wenn eine Ressource einen automatisch inkrementierenden 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 Nebeneffekte auf andere Ressourcen haben.
Ein Server kann die Unterstützung für PATCH
anzeigen, indem er es zur Liste in den Antwort-Headern Allow
oder Access-Control-Allow-Methods
(für CORS) hinzufügt.
Ein weiteres implizites Anzeichen dafür, dass PATCH
unterstützt wird, ist der Accept-Patch
-Header (normalerweise nach einer OPTIONS
-Anfrage für eine Ressource), der die Medientypen auflistet, die der Server in einer PATCH
-Anfrage für eine Ressource verstehen kann.
Anfrage enthält einen Body | Ja |
---|---|
Erfolgreiche Antwort enthält einen Body | Kann sein |
Sicher | Nein |
Idempotent | Nein |
Cachefähig | Nur wenn Frische-Informationen enthalten sind |
Erlaubt in HTML-Formularen | Nein |
Syntax
PATCH <request-target>["?"<query>] HTTP/1.1
<request-target>
-
Identifiziert die Zielressource der Anfrage, wenn kombiniert mit den im
Host
-Header bereitgestellten Informationen. Dies ist ein absoluter Pfad (z. B./path/to/file.html
) bei Anfragen an einen Ursprungsserver und eine absolute URL bei Anfragen an Proxies (z. B.http://www.example.com/path/to/file.html
). <query>
Optional-
Eine optionale Abfragekomponente, die mit einem Fragezeichen
?
eingeleitet wird. Wird häufig verwendet, um identifizierende Informationen in Form vonkey=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:
{
"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:
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 jeden der erfolgreichen Antwort-Statuscodes angezeigt werden.
In diesem Beispiel wird ein 204 No Content
verwendet, da es nicht notwendig ist, einen Body mit zusätzlichem Kontext zur Operation zu übertragen.
Ein ETag
wird bereitgestellt, sodass der Anforderer eine bedingte Anfrage in Zukunft durchführen kann:
HTTP/1.1 204 No Content
Content-Location: /users/123
ETag: "e0023aa4f"
Spezifikationen
Specification |
---|
RFC 5789 |
Browser-Kompatibilität
Der Browser verwendet die PATCH
-Methode nicht für vom Benutzer initiierte Aktionen, daher gilt "Browser-Kompatibilität" nicht.
Entwickler können diese Anforderungsmethode mit fetch()
setzen.
Siehe auch
- HTTP-Anforderungsmethoden
- HTTP-Antwortstatuscodes
- HTTP-Header
204
Allow
,Access-Control-Allow-Methods
HeaderAccept-Patch
– spezifiziert die vom Server akzeptierten Patch-Dokumentformate- JSON Patch Generator