Évaluateur JSON Patch (RFC 6902)｜Appliquez les 6 opérations et voyez le résultat
Exécutez un JSON Patch sur un document directement dans le navigateur, sans serveur. Les six opérations standard — add, remove, replace, move, copy et test — sont appliquées dans l'ordre, et vous obtenez le JSON modifié accompagné d'une trace lisible de ce qu'a fait chaque opération. Si une seule opération échoue, tout le patch échoue et le document d'origine est renvoyé, conformément au RFC 6902.
💡 À propos de cet outil
Quand vous concevez ou relisez un point d'accès PATCH, une question revient sans cesse : « si j'envoie ce tableau d'opérations, à quoi ressemble le document ensuite ? » Démarrer la vraie API, composer la requête et lire la réponse forme une boucle lente, surtout lorsque la différence entre move et copy, le résultat d'un test ou le comportement du jeton d'ajout - ne sont pas évidents.
Cet outil réduit cette boucle à deux zones de texte. Collez un document cible et un tableau d'opérations : chaque chemin est résolu avec la syntaxe JSON Pointer (RFC 6901), puis les opérations sont appliquées selon la spécification. En cas d'erreur, l'outil indique quelle opération a échoué (par exemple op[2]) et pourquoi : chemin inexistant, index de tableau hors limites, valeur de test non concordante ou opération inconnue. Il s'adresse aux développeurs back-end, aux relecteurs OpenAPI et à toute personne utilisant kubectl patch --type=json qui veut reproduire le comportement de la spécification sans solliciter un serveur réel.
🧐 Questions fréquentes
Q. Quelle est la différence entre JSON Patch (RFC 6902) et JSON Merge Patch (RFC 7396) ?
R. JSON Patch est un tableau d'opérations explicites (add, remove, replace, move, copy, test) appliquées dans l'ordre. Merge Patch envoie un document partiel décrivant l'état final voulu et utilise null pour supprimer une clé ; il n'a ni move, ni copy, ni test. Choisissez JSON Patch lorsque vous devez manipuler des tableaux avec précision ou vérifier une condition préalable.
Q. À quoi sert réellement l'opération test ?
R. C'est une garde qui vérifie qu'une valeur à un chemin donné correspond à votre attente avant toute mutation. Placer test /version == 15 en tête n'applique le reste du patch que si le document est encore dans l'état supposé : une manière propre de gérer la concurrence optimiste sans écraser la modification d'autrui.
Q. Que se passe-t-il si une opération échoue ? R. Le RFC 6902 traite le patch de façon atomique. Dès qu'une opération échoue, l'ensemble du patch est considéré comme échoué et l'outil renvoie le document cible d'origine intact. Aucune application partielle n'a lieu.
Q. Que signifie le - dans /user/tags/- ?
R. C'est le jeton spécial de JSON Pointer désignant « la fin du tableau ». Avec add, le - ajoute à la fin ; un index numérique insère plutôt à cette position.
Q. Comment référencer une clé contenant une barre oblique ou un tilde ?
R. Utilisez l'échappement du RFC 6901 : dans une clé, écrivez / sous la forme ~1 et ~ sous la forme ~0. Ainsi, une clé nommée littéralement a/b s'adresse par /a~1b.
📚 Pourquoi JSON Patch s'accorde si bien avec PATCH en REST
Le verbe PATCH de REST signifie « mise à jour partielle », mais HTTP ne définit pas le format du corps de la requête. Placer un JSON Patch dans ce corps permet de décrire un changement comme une suite d'opérations plutôt que comme un document de remplacement complet. Par rapport à PUT, la charge utile est légère, et associer les mutations à une opération test évite d'écraser en silence un champ que quelqu'un a modifié depuis votre lecture. Le tableau d'opérations sert aussi de journal d'audit lisible : on voit précisément qui a changé quel chemin et comment. Des outils comme kubectl patch --type=json acceptent ce même format RFC 6902. En pratique, la façon la plus rapide d'assimiler la différence entre move et copy, ou de ressentir comment test interrompt un patch, est d'aligner quelques opérations et d'observer le résultat plutôt que de relire la spécification.