Convertisseur GraphQL vers XML
Collez un schéma ou une requête GraphQL. Récupérez du XML propre.
Ce que fait cet outil
Si vous avez déjà dû documenter une API GraphQL pour une équipe qui ne travaille qu'en XML, ou brancher un schéma GraphQL sur un client SOAP hérité, vous connaissez la partie pénible : les types GraphQL ne se traduisent pas un pour un. Collez ici votre schéma ou votre requête et récupérez du XML bien formé en une seule passe. Quelques définitions type, un fichier SDL complet, ou une requête concrète avec arguments — même résultat : un document XML complet qui épouse la forme des données.
Le convertisseur connaît la spécification GraphQL, pas seulement la syntaxe de surface. Les valeurs par défaut des scalaires tombent comme vous l'attendez — String devient du texte, Int et Float deviennent du texte numérique, Boolean devient true/false, et ID devient une chaîne. Les marqueurs non-null (String!) et liste ([OrderItem!]!) sont respectés : une liste obligatoire apparaît comme un élément conteneur avec un enfant par item, et les champs nullables sans valeur ressortent en éléments vides pour que la forme du document reste stable.
Au-delà des types intégrés, l'outil gère aussi le reste du système de types. Les types input deviennent des éléments imbriqués, les valeurs enum sortent en texte, les types interface et union sont résolus vers leurs formes concrètes sous-jacentes, et les fragments (nommés ou inline) sont intégrés pour que la sortie reste plate et autonome. Les scalaires personnalisés comme DateTime, Date et JSON sont émis en ISO-8601 ou en valeurs sérialisées. Si vous collez une query avec arguments, ceux-ci sont conservés en tant qu'éléments de l'élément racine, de sorte que le XML reflète fidèlement la requête, pas juste un bloc de données.
Comment l'utiliser
Trois étapes. Même fonctionnement que vous colliez un seul type ou un schéma complet avec ses requêtes.
Collez votre GraphQL (ou essayez l'exemple)
Déposez le GraphQL tel quel dans l'éditeur de gauche. Un seul type, un fichier SDL complet avec input/enum/interface/union, ou une requête concrète avec variables — tout convient. Cliquez sur Charger un exemple si vous préférez partir d'une forme réaliste.
Pas besoin de retirer les commentaires ou de reformater la syntaxe SDL. Laissez-la comme votre éditeur l'a écrite — les docstrings entre triples guillemets et les commentaires en dièse passent sans souci.
Cliquez sur Convertir
Cliquez sur le bouton vert Convertir. L'outil lit le schéma (ou la requête), résout les fragments et les marqueurs liste/non-null, et construit le XML en une passe. Un court indicateur de chargement tourne pendant la conversion.
Copiez le XML
Le panneau de droite se remplit de XML indenté et bien formé qu'un parser XML conforme aux standards acceptera. Copiez-le directement dans votre requête SOAP, votre documentation, votre fixture ou votre exemple de XSD.
Quand c'est vraiment utile
Doc XML pour une API GraphQL
Doc interne ou partenaire qui vit en XML (DITA, DocBook, référence adossée à un XSD). Collez le schéma, récupérez des payloads XML d'exemple qui collent aux vrais types — sans traduction manuelle.
Générer des fixtures XML à partir d'un schéma
Tests de contrat, tests de snapshot, ou un serveur de mock qui parle XML. Donnez-lui le schéma que vous avez déjà et récupérez des fixtures XML cohérentes avec chaque liste, champ nullable et type imbriqué à la bonne place.
Passerelle vers des clients SOAP hérités
Un système partenaire n'accepte que du XML alors que votre backend parle GraphQL. Collez la requête et le type de réponse et récupérez un corps XML de départ à glisser dans la requête SOAP.
Migration et analyse de schéma
Quitter GraphQL pour une API XML (ou simplement comparer les deux formes). Obtenez une version XML côte à côte de chaque type pour que les relecteurs qui ne lisent pas le SDL puissent suivre.
Questions fréquentes
Comment type, input, enum, interface et union sont-ils gérés ?
type et input deviennent des éléments conteneurs avec un enfant par champ. Les valeurs enum sortent en texte simple (le nom de l'enum, en majuscules, exactement comme déclaré dans le SDL). interface se résout vers ses champs plus ceux du type implémentant, quand nous connaissons le type concret. union se résout vers la forme du membre correspondant. Voir la référence du langage de types GraphQL pour les règles complètes.
Quelles valeurs par défaut pour String, Int, Float, Boolean et ID ?
String et ID deviennent du contenu texte. Int est un entier brut. Float est un nombre décimal sans zéros de fin. Boolean est le texte en minuscules true ou false. Cela correspond aux définitions des scalaires de la spec GraphQL, de sorte que la sortie passe proprement par un parser XML.
Comment les marqueurs non-null (!) et liste ([T]) sont-ils traités ?
Le non-null (String!) est traité comme un champ qui doit apparaître — les champs nullables sans valeur ressortent en éléments vides pour que la forme du document reste prévisible. Les listes ([OrderItem!]!) deviennent un élément conteneur avec un enfant par item, nommé d'après le type d'élément — par ex. items: [OrderItem!]! devient <items><OrderItem/><OrderItem/></items>. Les listes imbriquées ([[Int]]) s'imbriquent de la même façon.
Les fragments sont-ils résolus ?
Oui. Les fragments nommés (...OrderFields) et inline (... on Order { ... }) sont intégrés pour que le XML reste plat et autonome. Pas besoin de coller les définitions de fragment séparément — s'ils sont dans le même bloc, l'outil les relie. Cela suit le modèle d'exécution classique des requêtes, où les fragments sont étalés dans le selection set avant la construction de la réponse.
Et les scalaires personnalisés comme DateTime ?
Les scalaires personnalisés les plus connus (DateTime, Date, Time, UUID, JSON) sont émis en texte ISO-8601 ou en valeurs sérialisées par convention — ce que font la plupart des bibliothèques de scalaires. Les scalaires inconnus retombent sur du texte, ainsi rien n'est perdu silencieusement. Si vous avez besoin d'un format précis, post-traitez le XML ou renommez le scalaire.
Puis-je coller une requête avec arguments, pas seulement un schéma ?
Oui. Collez une query avec variables et arguments — par ex. query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } — et les arguments ressortent en attributs sur l'élément racine. Les champs sélectionnés dictent quelles parties de la forme de réponse sont sérialisées, donc le XML correspond à ce que la requête renverrait réellement, pas au type complet.
Autres outils dont vous pourriez avoir besoin
GraphQL vers XML n'est qu'une pièce du puzzle. Ces outils s'y marient bien :