JSON vs YAML vs XML: cuándo usar cada uno de verdad

JSON, YAML y XML son todos capaces de representar esencialmente los mismos datos subyacentes — objetos anidados, listas, pares clave-valor, valores planos — que es exactamente por qué la elección entre ellos tan a menudo se reduce a la costumbre o a lo que un framework trae por defecto, en lugar de a una decisión meditada. Pero los tres se diseñaron en épocas distintas para casos de uso principales distintos, y esos objetivos de diseño originales todavía se manifiestan hoy como diferencias prácticas reales: cuál es agradable de editar a mano, cuál puede validarse estrictamente por una máquina, cuál se anida en profundidad sin volverse ilegible, y cuál ya cuenta con todo un ecosistema de herramientas que lo esperan. Elegir en base a esas diferencias, en lugar de a la costumbre, es lo que realmente hace que una elección de formato sea buena en lugar de meramente convencional.

JSON se extrajo directamente de la sintaxis de objetos literales de JavaScript, y ese origen es precisamente por qué se convirtió en el formato por defecto de intercambio de datos para APIs web: cualquier entorno de JavaScript puede analizarlo de forma nativa sin ninguna librería, su gramática es lo bastante pequeña como para implementarse correctamente en prácticamente cualquier otro lenguaje en una tarde, y sus reglas estrictas — sin comentarios, sin comas finales, claves entre comillas dobles obligatoriamente — significan que un analizador de JSON tiene muy poca ambigüedad que resolver, lo que hace que JSON sea rápido de analizar y fácil de generar correctamente. Esa misma severidad es la principal debilidad de JSON para cualquier cosa que una persona vaya a editar directamente a mano: sin comentarios significa que no hay forma de dejar una nota explicativa en un archivo de configuración, y la sintaxis de llaves anidadas cargada de puntuación se vuelve genuinamente difícil de seguir visualmente en cuanto una estructura se anida más de tres o cuatro niveles de profundidad.

Esto es por lo que JSON domina la comunicación entre máquinas — respuestas de API, intercambio de datos entre servicios, cualquier cosa generada y consumida principalmente por código en lugar de leída y editada por una persona — mientras sigue siendo una elección algo torpe para archivos de configuración que un humano debe mantener a mano.

YAML se diseñó con la prioridad opuesta: legibilidad humana y facilidad de edición manual, a costa de una especificación de análisis considerablemente más compleja que la de JSON. Usa indentación en lugar de llaves para representar el anidamiento, admite comentarios genuinos con `#`, y permite cadenas sin comillas en el caso común, todo lo cual hace que un archivo YAML bien formateado se lea casi como notas estructuradas en texto plano en lugar de código — que es exactamente por qué YAML se convirtió en el estándar para archivos de configuración en una enorme franja de herramientas de desarrollo: definiciones de pipelines de CI/CD, manifiestos de orquestación de contenedores, configuración de aplicaciones que un humano genuinamente necesita leer y modificar directamente. El costo es que la dependencia de YAML del espacio en blanco para la estructura lo hace genuinamente frágil de editar correctamente a mano — una indentación mal colocada cambia silenciosamente a qué bloque pertenece algo en lugar de lanzar un error obvio — y su especificación más permisiva y rica en funciones ha producido a lo largo de los años inconsistencias de análisis reales y documentadas entre distintas librerías de YAML, una ambigüedad para la que la gramática mucho más estricta de JSON simplemente no deja espacio.

XML es anterior tanto a JSON como a YAML y se diseñó de nuevo con una prioridad distinta: estructura de documento estricta y verificable, con un ecosistema maduro de estándares que lo rodean — lenguajes de esquema que pueden validar la estructura de un documento antes incluso de que el código de la aplicación lo toque, XPath para consultar dentro de un documento, espacios de nombres para combinar vocabularios de distintas fuentes sin colisiones de nombres. Esa profundidad de herramientas sigue siendo genuinamente insuperada por JSON o YAML en contextos empresariales y centrados en documentos: industrias con requisitos estrictos de intercambio de datos, formatos de documento estandarizados y sistemas heredados de larga vida construidos alrededor de él siguen confiando en XML precisamente por esa madurez de validación y herramientas, no por pura inercia. El conocido costo es la verbosidad — representar los mismos datos anidados en XML típicamente requiere notablemente más caracteres que el JSON equivalente, ya que cada valor necesita una etiqueta de apertura y cierre en lugar de un solo carácter de puntuación — que es la razón principal por la que XML perdió el papel de formato por defecto para APIs frente a JSON a medida que los servicios web maduraron y el tamaño del payload y la simplicidad de análisis se volvieron prioridades mayores que la validación estilo documento.

Para el cuerpo de una petición o respuesta de API, JSON es casi siempre la elección correcta por defecto hoy en día — es lo que la mayoría de librerías cliente, la mayoría de herramientas de documentación, y la mayoría de desarrolladores al otro lado de una integración esperarán con cero fricción. Para un archivo de configuración que una persona va a leer y editar a mano regularmente — pipelines de CI, configuración de aplicaciones, definiciones de infraestructura como código — los comentarios y el anidamiento más limpio de YAML se ganan de verdad su lugar, siempre que las herramientas alrededor validen la sintaxis con cuidado, ya que ahí es donde más muerde la fragilidad de YAML con el espacio en blanco. Para un formato centrado en documentos con una necesidad genuina de validación estricta de esquema, espacios de nombres para combinar vocabularios, o integración con un sistema empresarial basado en XML ya existente, la verbosidad de XML es un precio razonable por una madurez de herramientas que ninguno de los otros dos replica del todo. La elección de formato que realmente sirve bien a un proyecto es la que coincide con quién — o qué — va a leer y escribir el archivo con más frecuencia, no la que resulte ser el estándar más de moda del momento.