Même configuration : API en JSON, K8 en YAML, allers-retours en CI — un mauvais format entraîne des erreurs d'analyse, des commentaires perdus ou des déploiements dans le mauvais environnement.
Destiné aux ingénieurs full-stack et DevOps, cet article compare la syntaxe et les critères de sélection de JSON et YAML, décrit un workflow de conversion sécurisé en 5 étapes et les pièges tels que les ancres, les alias et les booléens implicites. Après cela, vous pouvez convertir et valider localement dans le navigateur à l'aide de la conversion JSON ↔ YAML de JSON Toolbox.
Pourquoi comprendre JSON et YAML est important
JSON est le standard de facto pour les API ; YAML est le langage de facto pour la configuration des opérations. Si vous basculez entre les deux sans connaître les différences, vous risquez : « Le YAML s'exécute localement, mais après la conversion JSON, les types de clés ont changé ».
Exemple Docker Compose : ports : "8080:8080" par rapport aux ports numériques dans JSON, ou oui/non dans K8 se manifeste sous forme booléenne dans YAML — comportement client incohérent après la conversion en JSON.
Que sont JSON et YAML
JSON (JavaScript Object Notation) est un format d'échange strict, basé sur du texte : clés entre guillemets doubles, sans commentaires, convivial pour l'analyseur. YAML (YAML Ain't Markup Language) utilise l'indentation pour la hiérarchie, autorise les commentaires et diverses notations scalaires – mieux pour les grandes configurations gérées manuellement.
Connexion
Dans YAML 1.2, JSON est un sous-ensemble : la plupart des documents JSON valides peuvent être analysés directement en tant que YAML. Les fonctionnalités spécifiques à YAML (ancre &, alias *, multi-ligne |) sont perdues lors de la conversion en JSON ou doivent être résolues.
Différences fondamentales en comparaison
| Dimension de comparaison | JSON | YAML |
|---|---|---|
| Commentaires | ❌ Non pris en charge | ✅ # Commentaire de ligne |
| Guillemets pour les clés | ✅Obligatoire (double) | ⚠️ Généralement facultatif |
| hiérarchie | Crochets bouclés/carrés | Indentation (espace) |
| Transport d'API | ✅ Recommandé | ⚠️ Rare |
| Grosses configs à la main | ⚠️ Beaucoup de parenthèses | ✅ Recommandé |
| Rigueur | Élevé – Analyser l'erreur immédiatement | Relativement lâche – types implicites |
Quel format pour qui ?
| Rôle/Scénario | Format recommandé | Raison |
|---|---|---|
| API REST/GraphQL | JSON | Un écosystème unifié, clairement |
| Kubernetes/Heaume | YAML | Convention communautaire, commentable |
| Docker Composer | YAML | Exemples officiels et documentation |
| package.json/tsconfig | JSON | Prise en charge de la chaîne d'outils native |
| Charge utile de la file d'attente de messages | JSON | Analyse compacte et rapide |
Scénarios typiques — guide de sélection
- Contrat API frontend/backend : JSON
- Actions GitHub / GitLab CI (étapes partielles) : YAML
- Configuration statique avant les variables d'environnement : selon l'équipe — YAML avec commentaires
- Structure à valider strictement par machine : JSON + schéma JSON
Pratique : 5 étapes pour une conversion en toute sécurité
- Définir la direction : JSON → YAML (lisible/modifiable) ou YAML → JSON (API/programmes)
- Enregistrer l'original : conserver la copie avant la conversion
- Insérez le contenu source sur la page de conversion, choisissez la direction
- Résultat de la vérification : JSON avec validateur ; YAML fait attention à l'indentation et aux types
- Test de fumée dans l'environnement cible : déployer ou appeler une fois - comportement comme avant
Exemple : la même config en deux notations
JSON :
__PRÉSERVE_CODE_0__YAML :
__PRÉSERVE_CODE_1__Pièges typiques lors de la conversion
Types YAML implicites
- oui/non/on/off peut être analysé comme booléen
- Chaînes de nombres purs entre guillemets, par ex. Version B : "01"
- null et ~ en YAML signifient vide — en JSON, il devient nul
Taille par JSON → YAML
YAML est souvent plus lisible, mais pas toujours plus court. La compression JSON + est toujours recommandée en production uniquement pour le transport.
Ancre et pseudonyme
YAML &anchor et *alias résolvent la duplication des objets lors de la conversion JSON - vérifiez si c'est ce que vous voulez.
Chaînes d'outils : JSON contre YAML
| Exigence | Chaîne d'outils JSON | Chaîne d'outils YAML |
|---|---|---|
| Conversion dans le navigateur | Boîte à outils JSON | Boîte à outils JSON |
| Validation CLI | jq | yamllint/yq |
| Appliquer les K8 | Premier YAML ou CRD JSON | kubectl appliquer -f |
| Contraintes de schéma | Schéma JSON établi | Des normes moins uniformes |
Questions fréquemment posées (FAQ)
N’importe quel JSON peut-il être converti en YAML ?
Standard JSON oui, sémantiquement équivalent. L’ordre des touches et le style d’indentation peuvent différer de ceux du YAML manuscrit — la sémantique reste la même.
Les commentaires YAML persistent-ils dans JSON ?
Non. JSON n'a pas de commentaires - ils sont perdus lors de la conversion. Enregistrez les informations importantes dans la documentation ou dans le fichier README.
Les ressources K8 sont-elles également disponibles au format JSON ?
Oui. kubectl prend en charge les manifestes JSON ; La communauté et Helm utilisent principalement YAML - convenez d'un format pour l'équipe.
Raisons les plus courantes des erreurs de conversion ?
JSON : virgule finale, guillemets simples. YAML : tabulation et espace mélangés, espace manquant après les deux points.
Les données sont-elles téléchargées sur un serveur ?
Non. La boîte à outils JSON convertit localement dans le navigateur, même pour les configurations internes (mais supprime toujours les valeurs sensibles).
Valider à nouveau après la conversion ?
Oui, recommandé. Vérifiez au moins la syntaxe JSON et testez lors de la préparation si la configuration fonctionne.
Conclusion et prochaines étapes
JSON se concentre sur la rigueur et l'interopérabilité, YAML sur la lisibilité et la convivialité des opérations. Règle générale : API et programme à programme → JSON ; grandes configurations statiques à la main → YAML ; Validez toujours et testez la fumée lors de la conversion.
Déterminez dans le référentiel quels types de fichiers nécessitent quel format et le format de construction est vérifié dans CI - de cette façon, vous évitez les incidents de production dus aux types YAML implicites.