JSON apparaît dans suffisamment de rôles différents pour qu’il vaille la peine de les séparer : le format est le même partout, mais ce que chaque cas d’utilisation en attend réellement diffère, et confondre l’un pour l’autre est une source courante de décisions embarrassantes (ajouter des commentaires à une charge utile d’API générée par machine, ou s’attendre à ce qu’un pipeline de journalisation NDJSON soit analysé comme un seul document JSON).
Charges utiles d’API REST
Le cas d’utilisation le plus courant par volume. Un corps de requête et un
corps de réponse sont chacun un document JSON, Content-Type: application/json,
généré par un côté et consommé par l’autre sans qu’aucun humain ne le lise
au milieu. Rien ici n’a besoin de commentaires ou de commodité d’édition
manuelle ; ce qu’il faut, c’est une grammaire sans ambiguïté que toutes les
langues analysent de la même manière, qui est la vraie force de JSON. Une
charge utile REST est aussi la forme pour laquelle le Validateur de JSON
Schéma existe : vérifier une réponse
contre le contrat que l’API devrait respecter, et voir exactement quel
champ le viole et pourquoi, avant que ce bug n’atteigne le code de
production qui suppose que le champ est là.
Configuration d’application
package.json, tsconfig.json, composer.json, et des dizaines de
configurations d’outils en plus. C’est le cas d’utilisation où le manque
de commentaires de JSON coûte réellement quelque chose : un paramètre sans
explication à côté, car le format n’a nulle part où en mettre. Certains
outils contournent cela avec une clé // comment que personne ne lit
programmatiquement, d’autres passent à YAML ou à un sur-ensemble de JSON
(JSON5, JSONC) qui ajoute les commentaires. Voir JSON vs YAML
pour le compromis complet ; la version courte est que les fichiers de
configuration édités à la main profitent souvent des commentaires de YAML,
tandis que la configuration générée et consommée entièrement par les outils
est correcte en JSON simple.
NoSQL et bases de données de documents
MongoDB stocke les documents en BSON, un format binaire qui est un sur-ensemble du modèle de données de JSON, et renvoie JSON (ou une syntaxe de shell semblable à JSON) lorsque vous l’interrogez. CouchDB et la plupart des magasins de documents acceptent et renvoient JSON directement. L’attrait ici est structurel : toute la pitch d’une base de données de documents est de stocker des données à peu près dans la forme que votre application utilise déjà, plutôt que de les normaliser en lignes et clés étrangères d’abord, et le modèle objet et tableau de JSON est assez proche des types natifs de la plupart des langues pour que la traduction soit presque gratuite.
Lignes de journalisation et données en flux : NDJSON
Un seul document JSON ne se diffuse pas bien : un analyseur a généralement besoin du tout avant de pouvoir produire une valeur, car un document n’est valide que lorsque son crochet de fermeture final arrive. Newline Delimited JSON (NDJSON) résout cela en faisant de chaque ligne sa propre valeur JSON complète et indépendante, donc un pipeline de journalisation, un sujet Kafka, ou un grand export peut être traité ligne par ligne sans maintenir tout le fichier en mémoire. Le Convertisseur JSON vers NDJSON convertit un tableau JSON en ce format ligne-par-enregistrement et en arrière, avec récupération pour un flux qui a une ligne malformée plutôt que d’échouer tout le fichier pour un mauvais enregistrement.
Stockage du navigateur
localStorage et sessionStorage ne stockent que des chaînes ; tout ce qui
est structuré entre en tant que JSON.stringify(value) et ressort en tant que
JSON.parse(stored). C’est aussi là où le problème de précision des nombres
que Types de données JSON expliqués couvre devient
un vrai bug plutôt qu’une curiosité : faire un aller-retour d’un grand ID
entier à travers localStorage via le propre JSON.parse du navigateur peut
silencieusement modifier la valeur, ce qui est exactement le mode d’échec
que les outils de ce site sont construits pour éviter et signaler plutôt
que reproduire.
Essayer avec vos propres données
Chaque outil mentionné ci-dessus s’exécute entièrement dans votre navigateur : rien ne colle dans le Formateur JSON, le convertisseur NDJSON, ou le Validateur de Schéma n’est jamais téléchargé n’importe où, ce qui compte le plus pour exactement le type de réponses d’API réelles et de fichiers de configuration dont parle cette page.