JSON vs YAML: ¿Por qué JSON se ha coronado como el rey del intercambio de datos?



"Si YAML es mucho más fácil de leer para los humanos, ¿por qué todas las comunicaciones de API utilizan JSON?"
"¿Dónde reside la fuerza de YAML y por qué JSON se ha convertido en el estándar?"

Batalla medieval de JSON vs YAML


1. El preludio de la guerra de formatos de datos

En el pasado, los desarrolladores necesitaban un 'estándar común' para intercambiar datos entre sistemas. En sus inicios, XML ocupó ese puesto.

<person>
    <name>Alice</name>
    <age>25</age>
    <skills>
        <skill>Python</skill>
        <skill>Django</skill>
    </skills>
</person>

Sin embargo, XML resultaba excesivamente verboso y pesado, ya que requería cerrar cada etiqueta individualmente, lo que dificultaba su lectura. Fue entonces cuando surgieron JSON y YAML como alternativas.


2. JSON: Se convierte en el estándar para el intercambio de datos web



En 2001, Douglas Crockford creó JSON, inspirándose en la notación de objetos de JavaScript. La clave era ser "lo más ligero posible y fácil de leer para las máquinas".

El secreto del éxito de JSON era claro: * Ligereza abrumadora: Transmite solo los datos, sin adornos innecesarios. * Compatibilidad perfecta con la web: Los navegadores (JavaScript) podían convertirlo directamente en objetos sin necesidad de librerías adicionales. * Mapeo intuitivo: Su estructura es casi idéntica a las estructuras de datos de lenguajes modernos, como los Dict de Python o los Object de JS.

Especialmente con el auge de las REST API como tendencia dominante en la web, JSON se convirtió, de hecho, en un lenguaje universal.


3. YAML: El formato nacido para ser leído por humanos

También existió un bando que se centró más en el "placer de la lectura humana" que JSON. De la pregunta "¿No podríamos escribirlo de forma más limpia, sin corchetes ni comillas?", nació YAML.

name: Alice
age: 25
skills:
  - Python
  - Django

Las características de YAML son claras: * Legibilidad extrema: Basado en la indentación, el texto es muy limpio. * Soporte de comentarios (#): La capacidad de añadir 'explicaciones', algo que JSON no tiene, es una gran ventaja. * El rey de los archivos de configuración: Gracias a esta legibilidad, ha dominado por completo los formatos de configuración de infraestructura como Kubernetes, Docker y GitHub Actions.

Pero, ¿por qué no logró superar a JSON en el intercambio de datos (API)?


4. Razones prácticas por las que YAML ha quedado relegado en el intercambio de datos

Primero, la rigurosidad de la indentación (espacios vs. tabulaciones): Mientras que en JSON los corchetes definen la estructura, en YAML un simple espacio invisible puede alterar toda la estructura. Al intercambiar datos complejos, un error en un espacio puede llevar a un infierno de depuración.

Segundo, la velocidad de análisis y los recursos: La sintaxis de JSON es tan simple que su analizador es muy ligero y rápido. Por el contrario, la sintaxis de YAML es tan extensa y compleja (incluso incluye funcionalidades de ejecución de código) que su análisis consume más memoria y CPU. Esto es crítico en entornos API donde se intercambian grandes volúmenes de datos.

Tercero, problemas de seguridad: YAML puede incluir la capacidad de invocar directamente objetos de lenguajes específicos, más allá de simples datos. Esto conlleva el riesgo de vulnerabilidades de seguridad, como la ejecución remota de código (RCE), lo que lo hace inadecuado para APIs que intercambian datos con un público masivo e indeterminado.


5. Al final, una cuestión de "uso adecuado"

Si JSON es el rey del intercambio de datos, YAML se ha consolidado como el rey de los archivos de configuración, afianzando cada uno su propio dominio.

  • Cuándo usar JSON: Para la comunicación en APIs web, el almacenamiento en bases de datos NoSQL y la transmisión de datos entre clientes.
  • Cuándo usar YAML: Para archivos de configuración de proyectos (docker-compose.yml), scripts de CI/CD y documentos que deben ser gestionados directamente por humanos.

Incluso en Django Rest Framework (DRF), aunque se puede añadir un YAMLRenderer, el valor predeterminado siempre es JSONRenderer. Porque los datos deben ser precisos y rápidos.


Conclusión: Un resumen en una frase

"Para la comunicación entre máquinas (API), JSON; para la comunicación entre humanos y máquinas (configuración), YAML."

Artículos relacionados: