Convertidor de GraphQL a XML
Pega un esquema o consulta GraphQL. Recibe XML limpio.
Qué hace esta herramienta
Si alguna vez te ha tocado documentar una API GraphQL para un equipo que solo trabaja con XML, o conectar un esquema GraphQL a un cliente SOAP heredado, ya conoces la parte incómoda: los tipos de GraphQL no se traducen uno a uno. Pega aquí tu esquema o consulta y obtén XML bien formado en una sola pasada. Un puñado de definiciones type, un archivo SDL completo o una consulta concreta con argumentos — el resultado es el mismo: un documento XML completo que refleja la forma de los datos.
El convertidor entiende la especificación de GraphQL, no solo la sintaxis superficial. Los valores por defecto de los escalares encajan como esperas: String se convierte en texto, Int y Float en texto numérico, Boolean en true/false, e ID en un valor de cadena. Los marcadores de no nulo (String!) y de lista ([OrderItem!]!) se respetan: una lista obligatoria aparece como un elemento contenedor con un hijo por cada ítem, y los campos anulables sin valor llegan como elementos vacíos para que la forma del documento se mantenga estable.
Más allá de los tipos integrados, la herramienta también cubre el resto del sistema de tipos. Los tipos input se convierten en elementos anidados, los valores de enum llegan como texto de cadena, los tipos interface y union se resuelven a sus formas concretas subyacentes, y los fragmentos (nombrados o en línea) se incrustan para que la salida sea plana y autocontenida. Los escalares personalizados como DateTime, Date y JSON se emiten como ISO-8601 o como valores serializados a cadena. Si pegas una query con argumentos, estos se conservan como parte del elemento raíz, de modo que el XML es un registro fiel de la petición, no solo un bloque de datos.
Cómo usarla
Tres pasos. Funciona igual tanto si pegas un único tipo como un esquema completo con consultas.
Pega tu GraphQL (o prueba el ejemplo)
Suelta el GraphQL tal cual en el editor de la izquierda. Un único type, un archivo SDL completo con input/enum/interface/union, o una consulta concreta con variables — todo vale. Pulsa Cargar ejemplo si prefieres empezar con una forma realista.
No hace falta quitar comentarios ni reformatear la sintaxis SDL. Déjalo tal y como lo dejó tu editor — los docstrings con triple comilla y los comentarios con almohadilla están bien.
Pulsa Convertir
Haz clic en el botón verde Convertir. La herramienta lee el esquema (o la consulta), resuelve fragmentos y marcadores de lista/no nulo, y construye el XML en una sola pasada. Un breve indicador de carga aparece mientras se procesa.
Copia el XML
El panel derecho se rellena con XML indentado y bien formado que cualquier parser XML conforme al estándar aceptará. Cópialo directamente en tu petición SOAP, documentación, fixture o ejemplo de XSD.
Cuándo te saca realmente de un apuro
Documentación en XML para una API GraphQL
Documentación interna o para partners que vive en XML (DITA, DocBook, referencias respaldadas por XSD). Pega el esquema y obtén payloads XML de ejemplo que encajan con los tipos reales — sin traducir a mano.
Generar fixtures XML a partir de un esquema
Tests de contrato, tests de snapshot o un servidor mock que habla XML. Pásale el esquema que ya tienes y obtén fixtures XML consistentes con cada lista, campo anulable y tipo anidado en su sitio.
Puente hacia clientes SOAP heredados
Un sistema socio solo acepta payloads XML pero tu backend habla GraphQL. Pega la consulta y el tipo de respuesta y obtén un cuerpo XML de partida para meterlo en la petición SOAP.
Migración y análisis de esquemas
Migrar de GraphQL a una API basada en XML (o simplemente comparar ambas formas). Obtén una versión XML lado a lado de cada tipo para que los revisores que no leen SDL puedan seguir el hilo.
Preguntas frecuentes
¿Cómo se tratan type, input, enum, interface y union?
type e input se convierten en elementos contenedores con un hijo por cada campo. Los valores de enum llegan como texto plano (el nombre del enum, en mayúsculas, tal y como se declara en el SDL). interface se resuelve a sus campos más los del tipo que la implementa cuando conocemos el tipo concreto. union se resuelve a la forma del miembro que corresponda. Consulta la referencia del lenguaje de tipos de GraphQL para las reglas completas.
¿Qué valores por defecto se usan para String, Int, Float, Boolean e ID?
String e ID se convierten en contenido de texto. Int es un entero plano. Float es un número decimal sin ceros finales. Boolean es el texto en minúscula true o false. Coinciden con las definiciones de escalares de la especificación de GraphQL para que la salida pase sin problemas por cualquier parser XML.
¿Cómo se tratan los marcadores de no nulo (!) y de lista ([T])?
El no nulo (String!) se trata como un campo que debe aparecer — los campos anulables sin valor llegan como elementos vacíos para que la forma del documento sea predecible. Las listas ([OrderItem!]!) se convierten en un elemento contenedor con un hijo por cada ítem, nombrado según el tipo del elemento — por ejemplo, items: [OrderItem!]! pasa a <items><OrderItem/><OrderItem/></items>. Las listas anidadas ([[Int]]) se anidan del mismo modo.
¿Se resuelven los fragmentos?
Sí. Los fragmentos con nombre (...OrderFields) y los fragmentos en línea (... on Order { ... }) se incrustan para que el XML sea plano y autocontenido. No hace falta pegar las definiciones de fragmento por separado — si están en el mismo bloque, la herramienta las enlaza. Esto coincide con el modelo normal de ejecución de consultas, donde los fragmentos se expanden en el conjunto de selección antes de construir la respuesta.
¿Qué pasa con los escalares personalizados como DateTime?
Los escalares personalizados más conocidos (DateTime, Date, Time, UUID, JSON) se emiten como texto ISO-8601 o como valores serializados a cadena por convención — lo que hacen la mayoría de las bibliotecas de escalares. Los escalares personalizados desconocidos caen en texto de cadena para que nada se pierda en silencio. Si necesitas un formato concreto, posprocesa el XML o renombra el escalar.
¿Puedo pegar una consulta con argumentos, no solo un esquema?
Sí. Pega una query con variables y argumentos — por ejemplo query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } — y los argumentos llegan como atributos en el elemento raíz. Los campos seleccionados determinan qué partes de la forma de respuesta se serializan, así que el XML coincide con lo que devolvería la consulta, no con el tipo completo.
Otras herramientas que puedes necesitar
GraphQL a XML es solo una pieza del rompecabezas. Estas herramientas encajan bien con ella: