JSON vs XML vs YAML: cómo elegir el formato de datos adecuado

Los mismos datos, de tres maneras

Abajo tienes un objeto pequeño representado en los tres formatos. Al compararlos lado a lado ves qué sacrifica cada uno.

{
  "user": {
    "name": "Ada Lovelace",
    "roles": ["admin", "editor"],
    "active": true
  }
}

user:
  name: Ada Lovelace
  roles:
    - admin
    - editor
  active: true

<user active="true">
  <name>Ada Lovelace</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

Los mismos tres campos, con cantidades de puntuación muy distintas. Esa diferencia es toda la historia: JSON es el más amigable para las máquinas, YAML es el más amigable para escribirlo a mano, y XML es el más expresivo cuando el documento en sí necesita estructura más allá de simples datos de clave/valor.

Dónde gana JSON

JSON se mapea directamente a las estructuras de datos que ya tiene todo lenguaje mainstream (objetos/dicts y arrays/listas), así que al analizarlo obtienes tipos nativos sin ambigüedad. No tiene comentarios, ofrece una sola forma de escribir cada valor y no es sensible a los espacios en blanco. Esos límites lo hacen rápido de analizar y seguro de generar desde código.

Usa JSON para cualquier comunicación máquina a máquina: cargas útiles de APIs REST y GraphQL, datos pasados entre servicios, cualquier cosa almacenada en una base de datos de documentos (MongoDB, JSONB de PostgreSQL) y cualquier configuración que se lea y escriba principalmente mediante código en lugar de editarse a mano.

Dónde gana YAML

YAML es un superconjunto estricto del modelo de datos de JSON con una sintaxis mucho más amigable para los humanos: sin llaves de cierre que contar, comentarios con # e indentación en lugar de puntuación. Eso quieres para archivos que una persona edita y relee en un diff: pipelines de CI (GitHub Actions, GitLab CI), manifiestos de Kubernetes y configuración de aplicaciones.

Esa flexibilidad es también la mayor trampa de YAML. Un error de indentación produce una estructura distinta sin ningún error de análisis, y el parser puede convertir valores sin comillas como `no`, `yes`, `on` y las fechas en booleanos o timestamps que no pretendías (el infame 'problema de Noruega', donde el código de país NO se convierte en el booleano false). Pon comillas a tus cadenas siempre que un valor admita dos lecturas.

Dónde gana XML

XML parece una carga heredada junto a JSON, pero hace cosas que ni JSON ni YAML pueden: atributos junto al contenido del elemento, contenido mixto (texto y elementos intercalados, como HTML), espacios de nombres para combinar vocabularios de distintas fuentes, y validación de esquemas madura (XSD) más herramientas de transformación (XSLT) que preceden a JSON por una década.

XML persiste en dominios centrados en documentos: APIs SOAP, SVG, DOCX/XLSX (archivos ZIP llenos de XML) y sistemas empresariales de banca, sanidad y gobierno con pipelines validados con XSD que nadie va a reescribir. Si tus datos tienen forma de documento ('un párrafo con un span en negrita en medio') y no de registro, XML suele encajar mejor.

Convertir entre formatos

Como los tres describen el mismo modelo de datos de objeto/array/string/number/boolean/null (los atributos y el contenido mixto de XML son lo único que no se mapea limpiamente), convertir entre JSON, YAML y XML suele ser mecánico para cualquier cosa con forma de registro. Las herramientas JSON to YAML, YAML to JSON, JSON to XML y XML to JSON de JsonForge hacen la conversión en el navegador, lo cual es útil cuando migras el formato de un archivo de configuración o necesitas entregar una exportación en JSON a un compañero que solo usa YAML.