Évaluateur JSON Merge Patch (RFC 7396) | Résultat fusionné et trace détaillée

Collez un JSON cible et un JSON patch pour appliquer les règles de fusion de RFC 7396, afficher le document obtenu et lire une trace ordonnée de chaque opération de définition, de suppression et de remplacement de la racine.

💡 À propos de cet outil

Lorsque vous concevez ou relisez un endpoint HTTP PATCH, vous voulez généralement savoir ce qu'un corps de patch fait réellement à la ressource stockée avant d'envoyer une vraie requête. RFC 7396 (JSON Merge Patch) paraît simple — vous envoyez un objet partiel et le serveur le fusionne — mais les cas limites piègent : null supprime un membre, les clés absentes restent intactes, les objets imbriqués sont fusionnés récursivement et les tableaux sont remplacés en bloc plutôt que fusionnés.

Cet évaluateur lève le doute. Collez la cible et le patch, et vous obtenez le JSON fusionné ainsi qu'une liste numérotée de ce qui a changé : définir /title = "Hello World", supprimer /author/email, et ainsi de suite. C'est cette trace qui fait la différence : au lieu de comparer deux blocs à l'œil, vous lisez les opérations exactes produites par la fusion, ce qui permet de vérifier qu'une spécification PATCH se comporte comme prévu et de repérer tôt un remplacement involontaire.

🧐 Questions fréquentes

Q. Quelle est la différence avec JSON Patch (RFC 6902) ? RFC 6902 est un tableau d'opérations explicites — add, remove, replace, move, copy, test — qui peut viser un index précis d'un tableau. RFC 7396 est déclaratif : vous envoyez un objet partiel décrivant l'état souhaité. Plus compact, il ne permet ni l'édition partielle d'un tableau ni l'affectation d'une valeur à null. Cet outil implémente uniquement RFC 7396.

Q. Puis-je modifier un seul élément à l'intérieur d'un tableau ? Non. Sous RFC 7396, les tableaux sont des valeurs opaques : tout tableau présent dans le patch remplace intégralement le tableau cible. Si vous avez besoin de changements au niveau de l'élément, c'est le signal qu'il faut passer à RFC 6902.

Q. Que se passe-t-il si je mets à null une clé absente de la cible ? Rien. Si la clé n'existe pas dans la cible, le null est sans effet : aucune suppression et rien dans la trace.

Q. Et si le patch est un scalaire ou un tableau au lieu d'un objet ? Le patch entier remplace la cible (RFC 7396 §2) et la trace affiche une seule entrée « remplacer la racine ». Un champ vide est traité comme null.

Q. L'ordre des clés est-il conservé ? La sortie est formatée, donc les clés nouvellement ajoutées peuvent apparaître vers la fin. RFC 7396 ne fixe pas l'ordre des clés ; comparez les résultats par équivalence sémantique plutôt qu'octet par octet.

📚 Le type de média qui change tout

Un détail souvent négligé de RFC 7396 est son type de média dédié, application/merge-patch+json. C'est lui qui permet à un serveur HTTP de distinguer « interprète ce corps comme un merge patch » d'un simple remplacement de type PUT : sans ce Content-Type, un même corps JSON pourrait écraser toute la ressource au lieu de la fusionner. Cette distinction explique pourquoi une route PATCH mal configurée efface parfois des champs que l'on croyait préservés. Lire la trace ordonnée des opérations aide justement à reproduire le comportement attendu de la fusion et à confirmer, opération par opération, ce que la cible deviendra avant d'envoyer la requête.