Résumé

  • Accept-Patch énumère les types de média que la ressource accepte comme documents de patch. Sa présence signale une capacité PATCH, mais elle n’authentifie pas l’appelant, ne lui accorde aucun droit d’écriture et ne valide pas la modification qu’il envisage.
  • Une mise en œuvre sûre traite séparément la découverte, le langage du document, la condition sur l’état et l’autorisation. L’annonce prépare une requête éventuelle ; seule cette requête, dans son contexte réel, permet de statuer.

Une réponse à OPTIONS contient deux valeurs : application/json-patch+json et application/merge-patch+json. Le client sait désormais que la ressource annonce deux grammaires de patch. Il ne sait pas si son compte peut écrire. Il ne sait pas si la version qu’il a lue est encore courante, ni si l’opération demandée respecte les règles métier. Il n’a reçu ni jeton ni consentement.

La confusion vient du sérieux apparent de la découverte. Le champ est enregistré, émis par le serveur et souvent voisin d’Allow. Une bibliothèque peut être tentée d’en déduire une propriété unique, « modifiable ». RFC 5789 ne justifie pas ce raccourci : le document définit l’annonce et exige par ailleurs que les requêtes soient autorisées.

Quatre décisions qui ne se remplacent pas

PATCH existe parce que PUT remplace une représentation complète, tandis qu’une modification partielle a besoin d’un document dont le type de média définit les instructions. L’URI cible désigne la ressource. Content-Type désigne le langage du patch. Une précondition peut lier l’action à un état observé. L’authentification et le contrôle d’accès décident si le principal peut agir.

Accept-Patch intervient en amont. Sa valeur est une liste de types de média, avec paramètres éventuels. Le champ devrait figurer dans la réponse OPTIONS de toute ressource prenant PATCH en charge. Présent dans la réponse à n’importe quelle méthode, il implique que PATCH est permis au niveau de cette ressource ; chaque type cité est annoncé comme admissible.

Le mot « permis » porte sur la capacité de la ressource, pas sur les droits de chaque personne. La section Sécurité de RFC 5789 distingue expressément autorisation, contrôle d’accès et authentification. Une réponse GET publique peut donc annoncer le même ensemble qu’un OPTIONS, alors qu’un PATCH anonyme recevra 401 ou 403. Deux comptes peuvent voir la même liste et disposer de périmètres d’écriture différents.

Les absences ont aussi un sens limité. PATCH peut apparaître dans Allow alors qu’Accept-Patch manque : la méthode est annoncée, les formats ne le sont pas. La présence du champ hors d’OPTIONS reste une indication de capacité. Aucun des deux cas ne promet la stabilité de la politique.

RFC 9110 rappelle que l’ensemble réellement autorisé des méthodes est fixé par le serveur d’origine au moment de chaque requête et peut évoluer dynamiquement. La découverte est une observation datée, non un bail sur la ressource.

Le type de média porte la sémantique

Il n’existe pas de format PATCH universel imposé à tous. Le serveur doit vérifier que le document reçu convient à la ressource ciblée. L’erratum vérifié 3169 rend la frontière encore plus nette : c’est le type de média du document qui définit comment PATCH s’applique. Un serveur ne doit pas inventer une sémantique de modification pour application/json ou application/xml simplement parce qu’il sait les parser.

application/json-patch+json, défini par RFC 6902, décrit une séquence ordonnée d’opérations comme add, remove, replace, move, copy et test. application/merge-patch+json, défini par RFC 7396, ressemble au document cible : la comparaison produit les ajouts et remplacements, tandis que null demande une suppression.

Les deux manipulent JSON sans être interchangeables. L’opération test de JSON Patch peut vérifier une hypothèse précise au milieu d’une séquence. Merge Patch est concis pour des objets, mais convient mal aux structures qui utilisent réellement null ou demandent une édition fine des tableaux. Une annonce qui cite les deux ne commande ni conversion automatique ni préférence générale.

Le client choisit donc consciemment un format et l’indique dans Content-Type. L’ordre de la liste ne suffit pas à décider. Des paramètres peuvent compter, et une modification déjà construite dans une grammaire ne devient pas correcte parce qu’une bibliothèque change son étiquette.

Une annonce peut accompagner un refus

RFC 5789 décrit plusieurs échecs possibles après la découverte. Un document mal formé peut donner 400. Un type non pris en charge peut donner 415 ; la réponse devrait alors inclure Accept-Patch et présenter les alternatives. Un document syntaxiquement valable mais inexécutable peut donner 422. Une ressource absente, lorsque le format ne sait pas partir du néant, peut conduire à 404. Un conflit d’état ou de concurrence peut donner 409. Une précondition explicite qui échoue appelle 412.

Le cas 415 révèle la fonction exacte du champ. Le serveur refuse la tentative tout en donnant une information utile pour une autre requête. L’annonce ne répare pas le document refusé, ne permet pas de changer seulement son Content-Type et ne garantit pas que l’alternative franchira l’autorisation ou la validation métier.

Le client devrait conserver l’échec, afficher les formats et décider s’il sait construire une nouvelle opération sémantiquement correcte. Cette opération sera jugée avec un nouvel état et un nouveau contexte d’autorisation. La découverte réduit l’incertitude ; elle n’impose pas de rejouer.

Une précondition protège la version, pas le privilège

Certains formats supposent une base connue. Deux clients peuvent fabriquer des changements à partir de la même version, puis rendre le second dangereux. RFC 5789 recommande alors une requête conditionnelle et cite un ETag fort dans If-Match.

RFC 9110 impose l’évaluation d’If-Match avant la méthode. La comparaison forte signifie : n’appliquez le changement que si la représentation courante correspond encore à celle que le client a observée. Un résultat faux mène à 412 et évite au serveur d’inventer une fusion.

Mais l’ETag n’est pas un secret. Un utilisateur sans droit peut connaître le bon validateur ; un utilisateur autorisé peut en envoyer un ancien. État et privilège nécessitent deux contrôles. Accept-Patch n’atteste ni l’un ni l’autre.

Le registre IANA qualifie PATCH de méthode non sûre et non idempotente. Une requête particulière peut être construite de façon idempotente, mais cela dépend du langage et des opérations. Répéter un ajout n’a pas le même effet que répéter un remplacement protégé par une condition. La liste des formats ne décrit pas cette propriété de la requête future.

L’atomicité commence après l’admission

Le serveur doit appliquer tout le document ou rien. Aucune représentation partiellement modifiée ne doit être exposée pendant l’exécution. Si une opération échoue, les changements du document ne doivent pas subsister.

RFC 6902 illustre la règle : l’échec d’une opération test fait échouer tout le JSON Patch. Ce contrat d’exécution ne signifie pas que tous les effets externes sont naturellement réversibles. RFC 5789 permet des effets applicatifs sur d’autres ressources et étend l’exigence aux éléments directement touchés.

Une architecture claire valide le type, authentifie, contrôle les chemins autorisés, évalue les préconditions, vérifie les contraintes métier puis engage atomiquement. Accept-Patch reste hors de cette transaction. Le lire ne réserve pas une version, ne crée pas de verrou et ne commence pas une modification.

Découverte et cohérence des caches

Après une réponse non erronée à une méthode non sûre, RFC 9111 impose au cache traversé d’invalider la cible. Location et Content-Location peuvent fournir d’autres candidats de même origine ; l’invalidation inter-origines est interdite dans ce cadre.

Ces conséquences suivent un PATCH effectivement exécuté, pas un OPTIONS qui annonce Accept-Patch. Transformer la découverte en signal d’invalidation créerait une commande que la spécification ne contient pas. Même après succès, l’invalidation ne touche que les caches du chemin, pas une infrastructure mondiale.

La signature ne change pas la portée

RFC 9421 permet de couvrir le champ par une signature de message. Une vérification réussie peut établir l’intégrité et l’authenticité des composants choisis dans un profil applicatif. Elle ne fabrique pas le droit d’écriture absent.

Le profil doit préciser les composants, les clés et la politique de confiance. Un protocole d’autorisation peut lier méthode, cible, contenu et identité, mais cette force vient de ce protocole supplémentaire. Une signature sur Accept-Patch protège l’annonce ; elle ne décide pas qui peut modifier quoi.

Modéliser sans confondre

Un client robuste conserve séparément l’URI et l’heure de l’observation, la présence de PATCH dans Allow, les types et paramètres annoncés, le validateur de la version de départ, puis l’identité et le contexte de sécurité employés pour la requête. Une interface peut réunir ces données, mais son stockage ne devrait pas les réduire à un booléen.

Du côté serveur, OPTIONS peut décrire une capacité stable sans dévoiler toute la politique par utilisateur. Le traitement du PATCH authentifie ensuite, autorise la cible et les opérations, valide Content-Type, interprète le bon langage, évalue If-Match, applique les règles métier et engage l’ensemble. Un 415 peut proposer des formats sans promettre le reste.

Les essais doivent croiser les cas : PATCH dans Allow sans liste ; liste dans une réponse GET ; même annonce pour un anonyme et un compte autorisé ; If-Match périmé ; refus d’application/json générique ; effets différents de JSON Patch et Merge Patch ; échec de test sans changement ; annonce signée suivie d’un 403.

L’errata mérite une discipline propre. La page courante compte trois corrections vérifiées et une rejetée. L’erratum 5521 retire Content-Location de l’exemple 204 ; il ne faut donc pas fonder une politique sur l’ancienne illustration. L’erratum 7513 corrige un lien interne sans changer la classification de PATCH. La proposition rejetée 3419 n’est pas une norme.

Sources