XML No Está Muerto (Desafortunadamente) — Convírtelo en JSON Como un Adulto

Aprendiste REST. Aceptaste JSON. Pensaste que la era de XML había terminado, como Flash o IE6 — algo que advertirías a los desarrolladores junior como una historia de fogata. Luego, tu nuevo cliente te entregó credenciales de API para su integración bancaria, y allí estaba: una envoltura SOAP de 400 líneas mirándote directamente a los ojos.

Bienvenido de nuevo al XML. Nunca se fue.

¿Por qué XML sigue por todas partes?

Para muchos desarrolladores que construyen aplicaciones modernas, XML parece un relicario. Pero en el mundo real — especialmente en software empresarial, bancario, de salud y en sistemas gubernamentales — el XML es infraestructura absolutamente esencial. Aquí es donde lo encontrarás:

• Servicios web SOAP – Aún es el estándar en instituciones financieras, plataformas de seguros y sistemas ERP grandes. Probablemente tu integración fintech pase por uno.
• APIs bancarias – Los mensajes ISO 20022, los mensajes SWIFT y muchas API de caja principal comunican en XML. No hay opción de REST.
• Datos gubernamentales – HMRC, el IRS y la mayoría de los portales gubernamentales aceptan o devuelven XML. Esto no cambiará pronto.
• Middleware empresarial – SAP, Oracle y los sistemas legados de ESB hablan nativamente en XML. Si estás integrando con algo de nivel empresarial, es muy probable que encuentres XML.
• Alimentaciones RSS y Atom – Aún en XML. Muchas cadenas de contenido, agregadores de noticias y herramientas de monitoreo dependen de ellas.

La verdad incómoda: XML no se irá porque los sistemas construidos sobre él no se irán. Reemplazar la infraestructura central de un banco no es una tarea de sprint. Así que, adapta.

XML vs JSON: Las diferencias estructurales que realmente te pillan por sorpresa

Antes de comenzar a convertir, ayuda entender por qué la conversión de XML a JSON no es simplemente un cambio de formato. Los dos formatos modelan los datos de manera diferente, y esas diferencias generan verdaderos problemas.

Lado a lado: Los mismos datos en ambos formatos

Tomemos un simple pedido de cliente. Aquí está en XML:

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

Y aquí está el equivalente en JSON:

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Ya puedes ver los puntos de fricción estructurales. Vamos a analizarlos.

Atributos vs Claves

Los elementos XML pueden llevar atributos (id="ORD-1042") junto con elementos secundarios y contenido de texto. JSON no tiene concepto de atributos — todo es un par clave-valor. La convención más común es prefijar los atributos con @ al convertir, dándote "@id": "ORD-1042". Algunos analizadores usan $ o los flaton completamente. La convención importa porque el código consumidor necesita saber qué prefijo esperar.

Arrays vs Elementos repetidos

Este punto molesta constantemente a los desarrolladores. En JSON, un array es explícito: [...]. En XML, no hay tal distinción — elementos hermanos repetidos son implícitamente una lista. Un analizador que ve un <item> elemento podría devolver un objeto. Dos <item> elementos? Devuelve un array. Tu código se rompe cuando la API devuelve un resultado único.

La solución es forzar arrays para campos conocidos como listas, o usar una biblioteca que preserve la información de tipo. Cuando estás convirtiendo datos aislados, verifica si un campo que parece un objeto único podría ser una lista en los payloads reales de producción.

Nodos de texto y contenido mezclado

Los elementos XML pueden contener tanto contenido de texto como elementos secundarios simultáneamente (contenido mezclado). JSON no puede representarlo de forma limpia. Los analizadores lo manejan de forma diferente — algunos usan una #text clave, otros usan _, otros simplemente eliminan el contenido mezclado. Si estás convirtiendo XML con contenido mezclado, verifica manualmente el resultado.

Espacios de nombres

Las respuestas SOAP están llenas de espacios de nombres XML: <ns2:getOrderResponse xmlns:ns2="http://...">. Dependiendo de tu analizador, estos se eliminan, se reducen al nombre de la clave (ns2:getOrderResponse) o se mapean a una URI. La mayoría de las veces deseas que se eliminen, pero si dos espacios de nombres comparten un nombre de elemento perderás la distinción. Conoce lo que estás trabajando antes de asumir que el resultado es limpio.

El camino rápido: Convertir XML en línea sin escribir un analizador

Si estás depurando una respuesta de API, explorando un esquema XML desconocido o haciendo una conversión de una vez, escribir un analizador es excesivo. Usa el Convertidor de XML a JSON — pega tu XML, obtén JSON limpio de inmediato y revisa la estructura antes de escribir cualquier código.

Maneja atributos (con convención de prefijo @ ), elementos anidados, elementos repetidos como arrays, y conserva el contenido de texto — lo cual cubre la mayoría de los payloads reales de API. Útil para entender rápidamente qué parece una respuesta SOAP una vez que se quita la envoltura.

Conversión programática: Qué usar en producción

Para código de producción que integre con APIs XML, se desea una biblioteca adecuada en lugar de escribir un analizador desde cero. Aquí están las opciones principales por lenguaje:

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser es la mejor opción para Node.js. Usa isArray para forzar el tratamiento como array para elementos conocidos como listas — esto evita el problema de inconsistencia entre un elemento y un array que eventualmente te golpeará en producción.

Pitón

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict es la opción estándar en Python. Usa la convención @ para atributos y #text para nodos de texto. Nota que devuelve un OrderedDict, que se serializa bien con json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

PHP’s simplexml_load_string + json_encode es el camino rápido, pero maneja los atributos de forma inconsistente y puede perder datos en casos extremos. Para trabajos de producción con respuestas SOAP, considera DOMDocument con LIBXML_NOBLANKS o una biblioteca dedicada.

Problemas comunes que debes vigilar

• Los números salen como cadenas. XML no tiene tipo numérico — todo es texto. Tu campo de precio será "49.99", no 49.99. Conviértelo explícitamente después de la conversión.
• Los valores booleanos permanecen como cadenas. <active>true</active> se convierte en "active": "true". Verifica antes de usarlos en condiciones.
• Los elementos vacíos se convierten en null o objetos vacíos. <middleName/> podría convertirse en null, "", o {} dependiendo del analizador. Prueba el caso extremo.
• Secciones CDATA pueden o no ser conservadas. Si la API usa CDATA para escapar contenido HTML, verifica que tu analizador lo maneje y no lo elimine silenciosamente.
• El orden no está garantizado. El orden de los elementos XML puede ser significativo en algunos esquemas; el orden de las claves en un objeto JSON no lo es. Si la secuencia importa para el sistema consumidor, manejarlo explícitamente.

Trabajar con SOAP específicamente

SOAP añade otra capa encima de XML: cada respuesta está envuelta en un <Envelope> con un <Body>, a menudo decorado con declaraciones de espacio de nombres y un <Header> bloque. Antes de convertir a JSON, normalmente deseas extraer solo el contenido del cuerpo.

En Python con zeep (el cliente SOAP), obtienes objetos de Python directamente y no necesitas analizar XML tú mismo. En Node.js, soap y strong-soap haz lo mismo. Si estás atacando un punto de entrada SOAP directamente con fetch o axios, necesitarás eliminar manualmente la envoltura antes de ejecutar tu conversor XML a JSON.

Para inspeccionar rápidamente respuestas SOAP, el Convertidor de XML a JSON es útil — pega la envoltura completa, ve la estructura completa y determina qué ruta lleva al dato que realmente necesitas.

Acepta la realidad y continúa

Existe un tipo de dolor que surge al darte cuenta de que tu proyecto de inicio de nivel debe integrarse con una API SOAP construida en 2003. Deja que te sientas, luego continúa. XML es un problema resuelto — los analizadores son maduros, las herramientas de conversión existen y los problemas son bien documentados. No eres el primer desarrollador que se enfrenta a una envoltura de 400 líneas.

Usa la biblioteca adecuada para tu lenguaje, maneja explícitamente la conversión de tipos, fuerza arrays para campos conocidos como listas y prueba con payloads reales en lugar de los ejemplos idealizados en las documentaciones de API. Las documentaciones mostrarán un solo ítem; la producción te enviará cincuenta.

Y para el trabajo exploratorio — entender un esquema XML desconocido, validar una conversión antes de escribir código — mantén el Convertidor de XML a JSON guardado. Es más rápido que ejecutar un script cada vez que necesitas inspeccionar un payload.

También te puede interesar