Zusammenfassung

  • Accept-Patch listet Medientypen auf, die eine Ressource als Patch-Dokumente akzeptiert. Das Feld signalisiert PATCH-Fähigkeit, authentifiziert aber keinen Aufrufer, verleiht kein Schreibrecht und validiert keine konkrete Änderung.
  • Ermittlung, Dokumentsprache, Zustandsbedingung und Autorisierung sind eigenständige Entscheidungen. Die Anzeige bereitet einen Request vor; erst der wirkliche Request in seinem Kontext kann die übrigen Fragen klären.

Eine OPTIONS-Antwort nennt application/json-patch+json und application/merge-patch+json. Der Client kennt nun zwei angebotene Grammatiken. Er weiß nicht, ob sein Konto schreiben darf, ob die gelesene Version aktuell ist oder die Operation Geschäftsregeln erfüllt. Eine Berechtigung hat er nicht erhalten.

Das Missverständnis entsteht, wenn eine formale Anzeige zu einem einzigen Merkmal „bearbeitbar“ verdichtet wird. Accept-Patch kommt vom Server, ist dauerhaft registriert und steht oft neben Allow. Dennoch definiert RFC 5789 die Formatanzeige und verlangt getrennt davon die Autorisierung der PATCH-Requests.

Ressourcenfähigkeit und Benutzerrecht

PATCH wurde nötig, weil PUT vollständigen Ersatz bedeutet, eine Teiländerung aber Anweisungen benötigt, deren Medientyp die Semantik festlegt. Die Ziel-URI nennt die Ressource, Content-Type die Patch-Sprache. Eine Vorbedingung bindet die Handlung an beobachteten Zustand. Authentifizierung und Zugriffskontrolle entscheiden über den Principal.

Accept-Patch steht davor. Es enthält Medientypen mit möglichen Parametern und sollte in OPTIONS für PATCH-fähige Ressourcen erscheinen. In einer Antwort auf irgendeine Methode zeigt seine Anwesenheit implizit an, dass die Ressource PATCH unterstützt; jeder genannte Typ wird dort als Patch-Format angeboten.

Dieses „erlaubt“ gilt für die Protokollfähigkeit, nicht für jede Identität. Der Sicherheitsabschnitt von RFC 5789 nennt Autorisierung, Zugriffskontrolle und Authentifizierung ausdrücklich. Ein öffentliches GET kann daher Formate anzeigen, während anonymes PATCH mit 401 oder 403 endet. Zwei Konten können dieselbe Liste und unterschiedliche Feldrechte haben.

PATCH darf in Allow stehen, obwohl Accept-Patch fehlt; dann ist die Methode, nicht aber das Format bekannt. RFC 9110 erklärt zudem, dass der tatsächlich erlaubte Methodensatz bei jedem Request bestimmt wird und dynamisch wechseln kann. Entdeckung ist eine zeitgebundene Beobachtung, keine Reservierung.

Der Medientyp trägt das Programm

Ein verpflichtendes Standardformat gibt es nicht. Der Server muss prüfen, ob das Dokument zur Zielressource passt. Das verifizierte Erratum 3169 verdeutlicht: Die PATCH-Anwendungssemantik stammt aus dem Medientyp. Parser-Unterstützung für application/json oder application/xml rechtfertigt keine erfundene Patch-Sprache.

JSON Patch verwendet application/json-patch+json und eine geordnete Folge von add, remove, replace, move, copy und test. JSON Merge Patch verwendet application/merge-patch+json, ähnelt dem Zieldokument, bestimmt Änderungen durch Vergleich und nutzt null als Löschanweisung.

Beide bearbeiten JSON, sind aber nicht austauschbar. test kann eine genaue Annahme prüfen. Merge Patch ist für Objektstrukturen knapp, jedoch ungeeignet, wenn null einen echten Wert trägt oder Arrays fein bearbeitet werden. Zwei Anzeigen ergeben weder automatische Konvertierung noch eine allgemeine Rangfolge.

Der Client wählt bewusst und setzt Content-Type. Nur das Etikett eines fertigen Dokuments zu wechseln, ändert seine Grammatik nicht.

Auch eine Ablehnung kann informieren

Ein angebotenes Format garantiert keinen Erfolg. Ein fehlerhaftes Dokument kann 400, ein nicht unterstützter Typ 415, syntaktisch richtige aber unverarbeitbare Anweisungen 422 ergeben. Für einen fehlenden, mit dem Format nicht erzeugbaren Gegenstand kommt 404 infrage, bei Zustands- oder Konkurrenzkonflikten 409 und bei gescheiterter Vorbedingung 412.

Eine 415-Antwort sollte Accept-Patch enthalten. Der Server lehnt ab und nennt Alternativen. Das Feld nimmt den gescheiterten Request nicht nachträglich an, erlaubt kein bloßes Umetikettieren und verspricht nicht, dass ein neues Dokument Zugriff und Geschäftsprüfung besteht.

Der Client kann die Ablehnung bewahren und lokal entscheiden, ob er einen semantisch neuen Request konstruieren kann. Entdeckung verringert Raten; sie befiehlt keine Wiederholung.

If-Match schützt Zustand, nicht Privileg

Auf einer bekannten Basis erzeugte Patches können nach einem konkurrierenden Update schädlich werden. RFC 5789 empfiehlt bedingte Requests und nennt ein starkes ETag in If-Match.

RFC 9110 lässt If-Match vor der Methode mit starkem Vergleich prüfen. Bei verändertem Zustand verhindert 412 eine erratene Neuanwendung. Das ETag ist aber kein Berechtigungsnachweis: Ein Unbefugter kann es kennen, ein Befugter kann ein altes senden. Zugriff und Zustand bleiben getrennte Prüfungen.

IANA registriert PATCH als unsicher und nicht idempotent. Ein einzelner Request kann idempotent konstruiert sein, doch das hängt von seinen Operationen ab. Accept-Patch beschreibt die Wiederholungswirkung des künftigen Dokuments nicht.

Atomarität beginnt bei der Ausführung

Der Server muss alle Änderungen oder keine anwenden. Ein Zwischenzustand darf nicht sichtbar sein; scheitert das Dokument, bleibt nichts davon bestehen. RFC 6902 illustriert dies mit einer fehlgeschlagenen test-Operation, die das gesamte JSON Patch unwirksam macht.

Diese Garantie gilt nach Zulassung des Requests und ist keine durch die Anzeige verliehene Macht. Da PATCH anwendungsdefinierte Nebenwirkungen auf andere Ressourcen haben kann, muss die Commit-Grenze direkt betroffene Elemente umfassen.

Eine klare Pipeline authentifiziert, autorisiert Ziel und Operationen, prüft Content-Type, parst die richtige Sprache, wertet If-Match und Geschäftsregeln aus und bestätigt atomar. Accept-Patch zu lesen startet weder Transaktion noch Sperre.

Cache und Signatur behalten ihre Grenzen

RFC 9111 verlangt nach einer nicht fehlerhaften Antwort auf eine unsichere Methode die Invalidierung der Ziel-URI in durchlaufenen Caches. Gleichursprüngliche Location- oder Content-Location-Werte können Kandidaten sein, fremde Origins nicht. Dies folgt einem wirklichen PATCH, nicht einem OPTIONS mit Accept-Patch, und garantiert keine globale Invalidierung.

RFC 9421 kann ausgewählte Komponenten signieren. Eine Signatur über Accept-Patch schützt innerhalb eines Profils Integrität und Authentizität, erzeugt aber keine Zugriffsentscheidung. Erst ein zusätzliches Autorisierungsprofil könnte Identität, Methode, Ziel und Inhalt binden.

Prüfbarkeit erhalten

Clients sollten Ressourcen-URI und Beobachtungszeit, Methodenanzeige, Typen und Parameter, Validator der Ausgangsversion sowie Identitätskontext getrennt speichern. Server können Fähigkeit mit OPTIONS beschreiben und bei PATCH authentifizieren, autorisieren, Format und Bedingung prüfen und atomar ausführen.

Tests brauchen Allow ohne Formatliste, eine Liste in GET, gleiche Anzeigen für unterschiedliche Rechte, veraltetes If-Match, abgelehntes generisches JSON, unterschiedliche Wirkungen beider JSON-Formate, fehlgeschlagenes test ohne Änderung und eine signierte Anzeige mit anschließendem 403.

Die aktuelle Errata-Seite enthält drei verifizierte und einen abgelehnten Eintrag. 5521 entfernt Content-Location aus dem 204-Beispiel; 7513 korrigiert nur einen Link; der abgelehnte Eintrag 3419 ändert den Standard nicht.

Quellen