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.