JSON, JavaScript Object Notation, est un format texte pour représenter des structures de données : objets, listes, chaînes, nombres, booléens et une valeur nulle, écrit dans une syntaxe assez petite pour être lue en un après-midi et assez stricte pour que tous les langages la parsent de la même manière. Il n’est pas lié à JavaScript malgré le nom. Tous les langages principaux livrent un analyseur JSON dans leur bibliothèque standard ou avec une installation en une ligne, ce qui est la vraie raison pour laquelle il a gagné : non pas parce qu’il est élégant, mais parce qu’il est ennuyeux et portable.
À quoi ça ressemble
{
"nom": "Ada Lovelace",
"age": 36,
"estEmployee": true,
"competences": ["mathematiques", "ecriture"],
"adresse": { "ville": "Londres", "pays": "UK" },
"surnom": null
}Un objet est { } contenant des paires clé-valeur, un tableau est [ ]
contenant une liste ordonnée, et tout le reste s’imbrique à l’intérieur de
ces deux conteneurs. C’est toute la forme de JSON : deux types de conteneur et
quelques types de valeur à l’intérieur.
Les six types de valeur, pas plus pas moins
Une valeur JSON est une chaîne, un nombre, un booléen (true ou false),
null, un tableau ou un objet. Rien d’autre n’existe dans la spécification.
Il n’y a pas de type date, pas de undefined, pas de syntaxe de commentaires,
et pas de moyen de représenter une fonction. Une date devient une chaîne dans
un format convenu par les deux parties (généralement ISO 8601), et une valeur
qui serait undefined en JavaScript est simplement omise de l’objet au lieu
d’être écrite. Types de Données JSON Expliqués
détaille chacun des six en plus, y compris les cas limites qui font planter
un analyseur naïf.
Pourquoi il a remplacé XML pour la plupart des API
XML enveloppe chaque valeur dans des balises d’ouverture et de fermeture, prend en charge des attributs en plus, et nécessite un langage de schéma séparateur pour décrire ce qui est valide. Les conteneurs JSON font deux caractères chacun, les valeurs sont typées sans balise pour vous le dire, et la forme du document reflète la forme de la structure de données qu’un programme utilise réellement ; analyser un document JSON en littéral objet natif d’un langage est presque une copie directe, là où un document XML nécessite généralement son propre modèle objet traduit par-dessus. C’est une différence réelle et mesurable en taille de charge utile et coût d’analyse, c’est pourquoi les API REST se sont stabilisées sur JSON une fois qu’il a existé. Voir JSON vs XML pour une comparaison plus proche et plus spécifique.
Où vous le croiserez réellement
- Réponses et requêtes d’API REST. Le format dominant pour les corps
Content-Type: application/json, dans les deux sens. - Fichiers de configuration.
package.json,tsconfig.json, et la plupart des configurations d’outils modernes, bien que YAML soit également courant ici ; voir JSON vs YAML pour quand chacun est préférable. - Bases de données NoSQL et de documents. Les documents MongoDB sont stockés en BSON, un sur-ensemble binaire de JSON, et la plupart des bases de données de documents acceptent et retournent JSON directement.
- Lignes de journal et pipelines de données, un objet JSON par ligne, un format généralement appelé NDJSON. Cas d’Utilisation JSON Courants détaille cela et les autres avec des formes réelles.
- Stockage du navigateur.
localStoragene stocke que des chaînes, donc toute donnée structurée passe parJSON.stringifyà l’entrée et parJSON.parseà la sortie.
Travailler avec
Collez un document dans le Formateur JSON pour le mettre en forme, ou dans le Validateur JSON pour le vérifier par rapport à la spécification avec une ligne et une colonne sur le caractère exact qui a échoué. Aucun ne télécharge ce que vous collez ; les deux s’exécutent entièrement dans votre navigateur. Une fois les bases comprises, la Aide Mémoire JSON est une référence d’une page pour les règles de syntaxe ci-dessus, à garder ouverte dans un onglet ou à télécharger pour une référence hors ligne.