Aller au contenu principal

JSON et YAML

CCNA — Automation and Programmability

JSON et YAML

Définition

JSON (JavaScript Object Notation) et YAML (YAML Ain't Markup Language) sont deux formats de données structurées. JSON décrit l'information avec des objets entre accolades et des tableaux entre crochets, syntaxe rigide faite pour être échangée entre machines. YAML utilise l'indentation et des séparateurs minimaux, pensée pour être écrite et relue par un humain. Aucun des deux ne configure directement un routeur : ils transportent ou décrivent des données que d'autres outils consomment.

Contexte

Le blueprint 200-301 v1.1, topic 6.7 (et 6.6 pour la reconnaissance des structures), demande de reconnaître les composants des données JSON et de comparer les cas d'usage de JSON et YAML. Attendu à l'examen : savoir lire un bloc JSON et identifier un objet, un tableau, une clé, un type de donnée; savoir lequel des deux formats sert au transport API et lequel sert aux fichiers de configuration; repérer une erreur d'indentation ou de tabulation en YAML. Les questions sont descriptives, jamais de la syntaxe pointue à écrire de mémoire.

JSON : objets et tableaux

JSON repose sur deux structures. Un objet est une collection de paires clé/valeur entre accolades, équivalent du dictionnaire Python. Un tableau (array) est une liste ordonnée entre crochets, équivalent de la liste Python. Les valeurs autorisées sont limitées à six types plus deux structures : string (entre guillemets doubles obligatoires), number, true/false, null, objet, tableau.

{
  "device": "R1",
  "interfaces": [
    {
      "name": "GigabitEthernet1",
      "adminStatus": "up",
      "ipAddress": [
        {
          "address": "10.10.10.1",
          "prefix-length": 24
        }
      ]
    }
  ],
  "ntp-servers": ["10.10.10.5", "10.10.10.6"],
  "tracked": true,
  "last-reboot": null
}

Quatre pièges de lecture fréquents à l'examen : les guillemets doubles sont obligatoires autour des clés et des chaînes (pas de guillemets simples, pas de virgule après le dernier élément); les commentaires n'existent pas; null n'est pas une chaîne; une accolade ouvrante se lit "objet", un crochet ouvrant se lit "tableau", y compris imbriqués.

Parser en Python tient en deux lignes avec la bibliothèque standard :

import json

with open("reponse_api.json") as f:
    data = json.load(f)          # bytes -> dictionnaire Python

data["interfaces"][0]["name"]     # 'GigabitEthernet1'
json.dumps(data, indent=2)        # dictionnaire -> texte JSON

Après json.load, un objet JSON devient dict, un tableau devient list : toute la navigation se fait avec les réflexes Python habituels. json.loads est la variante qui prend une chaîne déjà en mémoire au lieu d'un fichier.

YAML : mapping et séquence

YAML traduit les mêmes concepts avec moins de ponctuation : un mapping (dictionnaire) s'écrit cle: valeur, une séquence (liste) s'écrit avec des tirets. Les accolades, crochets et guillemets disparaissent presque tous ; seul le séparateur : compte, avec un espace obligatoire après les deux-points.

# inventaire.yaml - commentaire autorise en YAML
device: R1
interfaces:
  - name: GigabitEthernet1
    admin_status: up
    ip: 10.10.10.1/24
  - name: GigabitEthernet2
    admin_status: down
ntp_servers:
  - 10.10.10.5
  - 10.10.10.6
tracked: true

L'indentation porte le sens : les deux lignes sous interfaces: appartiennent à la séquence parce qu'elles sont décalées. C'est le point faible du format. Le standard YAML interdit les tabulations comme marqueur d'indentation, alors que la CLI et de nombreux éditeurs insèrent des tabs par réflexe : un fichier tabulé lève une erreur de parseur, souvent sans ligne précise, ce qui le rend pénible à déboguer. La règle pratique est de régler l'éditeur en 2 espaces par niveau, jamais de tab.

En Python, YAML passe par une bibliothèque externe (pip install pyyaml, puis yaml.safe_load(f)). safe_load et non load : ce dernier peut instancier des objets arbitraires depuis le document, faille connue quand le fichier vient d'une source non fiable.

Comparaison et cas d'usage

Critère JSON YAML
Structure de base objet {} / tableau [] mapping / séquence
Rôle dominant transport de données API fichiers de configuration, manifestes
Lisibilité humaine moyenne (ponctuation dense) élevée (bruit minimal, commentaires)
Commentaires aucun ligne #
Indentation non significative significative, tabulations interdites
Parser Python json (standard) pyyaml (tierce)
Exemple réseau payload REST/RESTCONF playbook Ansible, manifestes Kubernetes

Le partage de rôles est net dans l'écosystème réseau : les API REST répondent en JSON (cf. , ), tandis que les outils de gestion de configuration s'appuient sur YAML : un playbook Ansible est un fichier YAML, c'est exactement ce que vise le topic 6.6 du blueprint. Ansible décrit là une liste d'hôtes et de tâches, pas des données d'interface.

Exemple concret chiffré

Un même état d'interface, les deux formats, pour un script qui pousse la configuration d'un VLAN 100 sur 40 switchs. En JSON (corps d'une requête PATCH RESTCONF, 247 octets), la réponse du contrôleur revient telle quelle et se parse en 0,3 ms par json.loads. En YAML (variable Ansible, 138 octets sans accolades ni guillemets), l'humain relit la liste des 40 hôtes dans le hosts.yml d'inventaire sans effort. Sur ce projet de 40 devices, l'équipe a compté 7 corrections d'indentation YAML la première semaine, toutes dues à des tabulations collées depuis un wiki interne, et 0 erreur de syntaxe JSON, parce que les payloads venaient de json.dumps et non de la main. Le format le plus lisible pour l'œil reste le plus fragile à la frappe : c'est tout le compromis des deux formats.