L'histoire de JSON : de 2000 au standard de l'industrie

Douglas Crockford et l'origine

Au début des années 2000, Douglas Crockford, développeur JavaScript chevronné, en avait assez de XML, le format de données dominant de l'époque. XML était verbeux, difficile à analyser dans les navigateurs et disproportionné pour de simples transferts de données entre serveur et client.

Chez State Software, Crockford s'est rendu compte que la syntaxe des littéraux d'objets JavaScript pouvait déjà servir de format de données : compacte, lisible et comprise par tous les navigateurs. Il l'a nommée JSON (JavaScript Object Notation) et a enregistré json.org en 2002 pour publier la spécification.

La vague d'adoption du Web 2.0

Le grand déclic de JSON est arrivé avec le mouvement Web 2.0 (2005–2006). Alors que les applications basées sur AJAX avaient besoin de réponses serveur légères, les développeurs se sont tournés vers JSON plutôt que vers XML. Yahoo a été l'un des premiers à l'adopter, intégrant JSON dans plusieurs de ses services web.

Pendant un temps, les développeurs analysaient JSON avec eval(), rapide mais dangereux, car eval() peut exécuter du code arbitraire. ECMAScript 3.1 (devenu ES5 en 2009) a ajouté un JSON.parse() natif et sûr, supprimé ce risque et intégré JSON à la plateforme.

Devenir un standard

Ecma a formalisé JSON comme standard ECMA-404 en 2013, puis l'IETF l'a publié comme RFC 7159 en 2014 (révisé en RFC 8259 en 2017). Ces textes ont fait de JSON un standard indépendant du langage plutôt qu'une fonctionnalité de JavaScript.

À partir de là, l'adoption a été totale. Les API REST ont adopté JSON par défaut. Les bases de données NoSQL comme MongoDB stockent les documents au format JSON (BSON). Les fichiers de configuration, les jetons d'authentification JWT et les outils cloud natifs se sont tous standardisés sur JSON ou son sur-ensemble, YAML.

L'ère de eval() et de JSONP

Avant l'analyse native, les développeurs récupéraient des données inter-domaines avec JSONP : ils enveloppaient la réponse JSON dans un nom de fonction callback et la chargeaient comme balise <script>, en contournant la règle de même origine. Ça marchait partout, mais la page appelante devait faire entièrement confiance au fournisseur de données, puisqu'une balise script exécute tout ce qu'elle reçoit.

Ce problème de confiance a mal vieilli. À mesure que les API se multipliaient, JSONP est devenu un vecteur d'injection courant, et l'industrie a avancé : CORS a standardisé de véritables requêtes inter-origines, et JSONP est aujourd'hui une curiosité historique que vous ne rencontrerez que dans d'anciennes bases de code.

L'écosystème JSON moderne

JSON a dépassé le rôle de format de transport. JSON Schema est devenu un écosystème de validation avec son propre processus de drafts, à la base de contrats d'API et de générateurs de code. Des variantes sont apparues pour des niches précises : JSON5 assouplit la syntaxe pour les fichiers édités à la main, BSON stocke les documents de MongoDB dans un format binaire, NDJSON (JSON délimité par des retours à la ligne) diffuse des enregistrements ligne par ligne pour les logs et les transferts massifs, et JSONC (JSON avec commentaires) subsiste dans des fichiers de configuration comme ceux de VS Code.

La gouvernance du format s'est aussi stabilisée : la RFC 8259 (2017) est la norme Internet actuelle, aux côtés de l'ECMA-404. Le site d'origine de Douglas Crockford, json.org, reste en ligne, à la fois référence de la spécification et morceau d'histoire du web.

Pourquoi JSON a supplanté XML

JSON est environ 30 à 40 % plus petit que le XML équivalent (pas de balises fermantes, pas d'attributs), correspond directement aux structures de données natives de chaque langage et s'analyse bien plus vite. XML garde ses niches (balisage de documents, SOAP, configuration avec schémas), mais JSON domine l'échange de données.