Bidirectionnel
JSON → XML ou XML → JSON. Pour voir comment les champs deviennent des balises, pas pour pousser en production d’un coup.
Ensuite, passez encore le validateur du système cible.
Vous pouvez aussi injecter des données via #data={"name":"Ada"} ou #url=... Elles sont lues puis retirées de la barre d’adresse.
Conversion JSON ↔ XML. Pour une ancienne API qui renvoie encore du XML, ou un système qui n’accepte que XML, convertissez d’abord en local pour voir la structure. Le nom de l’élément racine est modifiable, par défaut rootConversion JSON ↔ XML. Pour une ancienne API qui renvoie encore du XML, ou un système qui n’accepte que XML, convertissez d’abord en local pour voir la structure. Le nom de l’élément racine est modifiable, par défaut
JSON → XML ou XML → JSON. Pour voir comment les champs deviennent des balises, pas pour pousser en production d’un coup.
Ensuite, passez encore le validateur du système cible.
Un objet correspond à des éléments imbriqués, un tableau à des balises répétées. Convention courante, pas forcément celle du schema distant.
Attributs vs éléments enfants varient selon les systèmes : à contrôler.
La représentation JSON des attributs XML et des nœuds texte peut différer du système d’origine : contrôlez après conversion.
Un document SOAP avec espaces de noms se convertit rarement parfaitement en automatique.
{
"note": {
"to": "Ada",
"body": "hello"
}
}
<note>
<to>Ada</to>
<body>hello</body>
</note>
Pour du SOAP complexe / xmlns, vérifiez à la main : l’auto-conversion conserve rarement tous les détails d’espaces de noms.
La config moderne utilise souvent YAML ; bus d’entreprise, certains paiements / administrations restent en XML.
JSON n’a pas de « balise racine » unique. En XML, ce nom enveloppe tout le document.
Oui. Après changement du nom racine, relancez la conversion.
Cette page répond à « voir d’abord la structure ». Un XSD / SOAP strict ne doit pas reposer seulement sur l’auto-conversion.