JSON vs YAML : Pourquoi JSON a-t-il conquis le trône de l'échange de données ?

"YAML est tellement plus facile à lire pour un humain, alors pourquoi toutes les communications API utilisent-elles uniquement JSON ?" "Quels sont les atouts de YAML et pourquoi JSON est-il devenu le standard ?"

JSON vs YAML : Bataille médiévale

1. Prélude à la guerre des formats de données

Dans le passé, les développeurs avaient besoin d'un 'standard commun' pour échanger des données entre systèmes. Au début, le XML occupait cette place.

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

Cependant, le XML était trop verbeux et lourd, nécessitant la fermeture de chaque balise. Sa lecture était également fastidieuse. C'est à ce moment que JSON et YAML sont apparus comme des alternatives.

2. JSON : Le standard de l'échange de données web

En 2001, Douglas Crockford a créé JSON en s'inspirant de la notation des objets JavaScript. L'idée maîtresse était d'être "aussi léger que possible et facile à lire pour les machines".

Les raisons du succès de JSON étaient claires : * Légèreté écrasante : Il transmet uniquement les données, sans fioritures inutiles. * Compatibilité parfaite avec le web : Il pouvait être directement converti en objet dans le navigateur (JavaScript) sans nécessiter de bibliothèque supplémentaire. * Mappage intuitif : Sa structure correspond presque parfaitement aux structures de données des langages modernes, comme les Dict de Python ou les Object de JS.

En particulier, avec l'avènement des API REST comme norme prédominante sur le web, JSON est de facto devenu la langue universelle.

3. YAML : Le format né pour être lu par l'humain

Il y avait aussi un courant qui se concentrait davantage sur le "plaisir de lire pour l'humain" que JSON. C'est de cette réflexion – "ne pourrait-on pas écrire de manière plus propre, sans accolades ni guillemets ?" – qu'est né YAML.

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

Les caractéristiques de YAML sont claires : * Lisibilité extrême : Basé sur l'indentation, le texte est très propre. * Support des commentaires (#) : La possibilité d'ajouter des 'explications', absente de JSON, est un atout majeur. * Champion des fichiers de configuration : Grâce à cette lisibilité, il a complètement dominé les formats de configuration d'infrastructure tels que Kubernetes, Docker et GitHub Actions.

Mais alors, pourquoi n'a-t-il pas surpassé JSON pour l'échange de données (API) ?

4. Les raisons pratiques pour lesquelles YAML a été éclipsé dans l'échange de données

Premièrement, la rigueur de l'indentation (Espace vs Tabulation) : Alors que JSON utilise des accolades pour structurer les données, YAML repose sur un simple espace invisible pour définir sa structure. Lors de l'échange de données complexes, une seule erreur d'espace peut transformer le débogage en un véritable enfer.

Deuxièmement, la vitesse de parsing et les ressources : La syntaxe de JSON est simple, ce qui rend son analyseur léger et rapide. En revanche, la syntaxe de YAML est vaste et complexe (incluant même des fonctionnalités d'exécution de code), ce qui consomme plus de mémoire et de CPU pour son interprétation. C'est un inconvénient majeur dans un environnement API où de grandes quantités de données sont échangées.

Troisièmement, les problèmes de sécurité : YAML peut inclure des fonctionnalités permettant d'appeler directement des objets d'un langage spécifique, au-delà de simples données. Cela risque de créer des vulnérabilités de sécurité, comme l'exécution de code à distance (RCE), le rendant inadapté pour les API qui échangent des données avec un public non spécifié.

5. En fin de compte, une question de « bon usage »

Si JSON est le roi de l'échange de données, YAML a fermement établi son règne en tant que roi des fichiers de configuration.

Quand utiliser JSON : Pour la communication via API web, le stockage dans les bases de données NoSQL, et le transfert de données avec le client.
Quand utiliser YAML : Pour les fichiers de configuration de projet (docker-compose.yml), les scripts CI/CD, et les documents que les humains doivent gérer directement.

Même dans Django Rest Framework(DRF), bien qu'il soit possible d'ajouter un YAMLRenderer, la valeur par défaut est toujours JSONRenderer. Car les données doivent être précises et rapides.