Formater JSON

JSON—JavaScript Object Notation—est le format textuel omniprésent pour l'échange de données structurées. Il est normalisé à la fois par l'IETF sous la référence RFC 8259 et par Ecma International sous la référence ECMA-404, qui définissent ensemble la syntaxe compacte et indépendante du langage qui alimente les API, les journaux, les configurations et les bases de données modernes.

Syntaxe et encodage : les bits précis qui permettent aux systèmes de communiquer

Une valeur JSON est soit un objet, un tableau, une chaîne de caractères, un nombre, ou l'un des littéraux true, false, ou null; les objets associent des chaînes de caractères à des valeurs et les tableaux contiennent des valeurs ordonnées — avec des espaces blancs insignifiants autorisés autour des caractères structurels (RFC 8259, ECMA-404). Bien que JSON soit originaire de JavaScript, il est indépendant du langage et pris en charge pratiquement partout (MDN : JSON). Sur le réseau, l'encodage de facto et recommandé est UTF-8 (RFC 8259 §8.1). Pour une sécurité d'interopérabilité supplémentaire, le profil I-JSON (RFC 7493) renforce les règles concernant les encodages et les plages numériques.

En JavaScript, l'objet global JSON expose deux piliers :JSON.parse (avec un reviver optionnel) et JSON.stringify (avec un remplaçant/espacement pour une impression jolie), comme documenté sur MDN (parse, stringify).

Nombres : faussement simples, étonnamment pointus

La grammaire des nombres de JSON est décimale, mais la spécification ne dicte pas la précision ou les distinctions entre entiers et flottants. Les implémentations choisissent comment les représenter (RFC 8259 §6). En JavaScript et Node.js, Number est en double précision IEEE-754, ce qui signifie que seuls les entiers dans [−(2^53−1), 2^53−1] sont exactement sûrs — voir Number.MAX_SAFE_INTEGER et le type BigInt. C'est pourquoi les API publiques envoient souvent les ID sous forme de chaînes de caractères et valident explicitement les « entiers sûrs ».

Au-delà du JSON de base : pointeurs, patchs et patchs de fusion

À mesure que l'utilisation a mûri, des normes ont émergé pour adresser et modifier JSON sur place. JSON Pointer (RFC 6901) est une syntaxe minuscule délimitée par des barres obliques pour localiser des valeurs (par ex., /a/b/0) avec des règles d'échappement pour ~ et /. JSON Patch (RFC 6902) modélise les mises à jour partielles comme des opérations ordonnées (add, remove, replace, move, copy, test) et transite en tant que application/json-patch+json. Pour des différences plus simples, JSON Merge Patch (RFC 7386) utilise une fusion en forme de document : les champs présents sont ajoutés/remplacés ; définir un champ à null le supprime. De nombreux frameworks prennent en charge l'une ou les deux formes nativement.

Schémas et types : validation et génération

JSON lui-même est sans schéma, mais les écosystèmes s'appuient sur des schémas pour la validation, la documentation et la génération de code. La famille JSON Schema 2020-12 spécifie des contraintes like type, properties, items, et des mots-clés de composition, et s'aligne avec OpenAPI 3.1. Pour les flux de travail centrés sur la génération de code, JSON Type Definition (RFC 8927) offre un langage délibérément moins expressif qui se mappe de manière prévisible aux systèmes de types courants.

Streaming et big data : lignes et séquences JSON

Le JSON classique attend un texte complet par charge utile, ce qui complique le streaming des journaux et les réponses de longue durée. Deux modèles aident :

• Séquences de texte JSON (RFC 7464) : un flux de textes JSON UTF-8, chacun préfixé par le Séparateur d'enregistrement (U+001E) et terminé par LF ; enregistré en tant que application/json-seq.
• NDJSON / JSON Lines : chaque ligne est une valeur JSON autonome — facile à suivre, à compresser avec gzip et à map-reduce (ndjson.org, jsonlines.org). Il est populaire dans les API en vrac, par ex., l' API en vracd'Elasticsearch.

Cousins binaires : quand le texte n'est pas assez compact

Lorsque la bande passante ou la vitesse domine, les formats « JSON binaire » préservent le modèle de données de JSON tout en échangeant la lisibilité humaine contre l'efficacité :

• BSON (format natif de MongoDB) ajoute des types comme binaire, date/heure et entiers typés (bsonspec.org).
• MessagePack est compact et sans schéma, largement implémenté dans plusieurs langues (msgpack.org).
• CBOR normalise un format extensible et compact (avec des conseils de transcodage JSON) et est courant dans les contextes IoT/contraints (RFC 8949, cbor.io).
• Smile (de l'écosystème Jackson) encode JSON avec des références arrière optionnelles pour les noms/valeurs répétés (jackson-dataformat-smile).

Notes de sécurité : vieilles astuces et correctifs modernes

Parce que JSON n'est que du texte, la plupart des risques proviennent de la façon dont vous le transportez et le manipulez :

• JSONP (demander des données via <script> avec un rappel) était une solution de contournement pré-CORS pour les requêtes inter-origines mais est dangereux — il exécute des scripts arbitraires. Préférez CORS avec de vraies réponses application/json (OWASP : Abus de JSONP).
• Détournement de JSON : les points de terminaison GET naïfs renvoyant des tableaux sensibles pourraient être volés via des balises de script inter-origines dans les anciens navigateurs ; les mesures d'atténuation incluent POST avec des protections CSRF ou le préfixage avec un sentinelle non-JSON (OWASP : Détournement de JSON).
• Injection de JSON : traitez JSON comme des données, pas comme du code ; échappez soigneusement et validez les entrées (OWASP : Injection de JSON).

Types de médias et héritage

JSON a fait ses débuts sous RFC 4627 (2006); le type de média enregistré est application/json, dont la spécification pointe maintenant vers RFC 8259. Les paramètres « charset » sur les réponses JSON sont généralement inutiles car UTF-8 est la valeur par défaut sur l'Internet public.

Conseils pratiques pour un JSON robuste en production

• Utilisez UTF-8 par défaut partout ; supposez UTF-8 en entrée et en sortie (RFC 8259 §8.1).
• Soyez explicite avec les grands entiers : si un ID peut dépasser 2^53−1, envoyez-le en tant que chaîne de caractères et documentez-le (MDN : MAX_SAFE_INTEGER).
• Validez les charges utiles avec JSON Schema 2020-12 (ou JTD pour les piles lourdes en génération de code). Publiez les schémas à côté de la documentation de votre API (OpenAPI 3.1).
• Utilisez les patchs à bon escient : utilisez JSON Patch pour les différences au niveau de l'opération et Merge Patch pour les mises à jour simples en forme de document.
• Streamez à grande échelle : choisissez Séquences de texte JSON ou NDJSON pour les journaux et les réponses de longue durée ; rendez le type de média explicite.
• Passez au binaire ( BSON, MessagePack, CBOR, Smile) lorsque le texte est le goulot d'étranglement, mais assurez-vous que les deux extrémités sont d'accord sur les types.

Un petit mot sur les « JSON plus conviviaux »

Les développeurs veulent souvent des commentaires, des virgules finales ou des chaînes de caractères entre guillemets simples dans les configurations. C'est en dehors du JSON standard, mais JSON5 fournit un sur-ensemble bien documenté pour les fichiers édités par l'homme. Évitez d'envoyer JSON5 via des API publiques, sauf si vous contrôlez les deux extrémités.

Le succès de JSON vient d'une petite surface, d'un large soutien linguistique et d'un cercle de normes adjacentes — pointeurs, patchs, schémas, séquences — qui couvrent les réalités désordonnées des systèmes distribués. Comprenez les fondamentaux (syntaxe, encodage, nombres), appuyez-vous sur les bonnes normes adjacentes et il continuera à porter ses fruits sur toutes les piles et tous les services (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).