A história do JSON: de 2000 a padrão da indústria

Douglas Crockford e a origem

No início dos anos 2000, Douglas Crockford, desenvolvedor JavaScript veterano, estava cansado do XML, o formato de dados dominante da época. O XML era verboso, difícil de analisar nos navegadores e exagerado para passar dados simples do servidor ao cliente.

Trabalhando na State Software, Crockford percebeu que a sintaxe de literais de objeto do JavaScript já servia como formato de dados: compacta, legível por humanos e entendida por todos os navegadores. Ele a batizou de JSON (JavaScript Object Notation) e registrou json.org em 2002 para publicar a especificação.

A onda de adoção da Web 2.0

O grande impulso do JSON veio com o movimento da Web 2.0 (2005–2006). À medida que aplicações baseadas em AJAX precisavam de respostas leves do servidor, os desenvolvedores migraram para o JSON em vez do XML. O Yahoo foi um dos primeiros a adotar, entregando JSON em vários de seus serviços web.

Durante um tempo, os desenvolvedores analisavam JSON com eval(), rápido porém perigoso, porque eval() pode executar código arbitrário. O ECMAScript 3.1 (que virou o ES5 em 2009) adicionou um JSON.parse() nativo e seguro, eliminou esse risco e tornou o JSON parte da plataforma.

Tornando-se um padrão

A Ecma formalizou o JSON como padrão ECMA-404 em 2013, e a IETF o publicou como RFC 7159 em 2014 (revisado como RFC 8259 em 2017). Esses documentos fizeram do JSON um padrão independente de linguagem, e não mais uma funcionalidade do JavaScript.

A partir daí, a adoção foi total. As APIs REST passaram a usar JSON por padrão. Bancos de dados NoSQL como o MongoDB armazenam documentos como JSON (BSON). Arquivos de configuração, tokens de autenticação JWT e ferramentas nativas da nuvem todos se padronizaram no JSON ou em seu superconjunto, o YAML.

A era do eval() e do JSONP

Antes do parsing nativo, os desenvolvedores buscavam dados entre domínios com JSONP: envolviam a resposta JSON em um nome de função callback e a carregavam como tag <script>, contornando a same-origin policy. Funcionava em todo lugar, mas a página que chamava precisava confiar por completo no provedor de dados, já que uma tag script executa tudo o que recebe.

Esse problema de confiança não envelheceu bem. À medida que as APIs se multiplicavam, o JSONP tornou-se um vetor de injeção comum, e a indústria seguiu em frente: o CORS padronizou requisições entre origens de verdade, e o JSONP hoje é uma curiosidade histórica que você só encontrará em bases de código antigas.

O ecossistema JSON moderno

O JSON foi além do formato de transmissão. O JSON Schema cresceu até virar um ecossistema de validação com seu próprio processo de drafts, base de contratos de API e geradores de código. Variantes surgiram para nichos específicos: o JSON5 relaxa a sintaxe para arquivos editados por humanos, o BSON guarda os documentos do MongoDB em formato binário, o NDJSON (JSON delimitado por novas linhas) transmite registros linha a linha para logs e transferências em massa, e o JSONC (JSON com comentários) continua vivo em arquivos de configuração como os do VS Code.

A governança do formato também se estabilizou: a RFC 8259 (2017) é o Internet Standard atual, ao lado da ECMA-404. O site original de Douglas Crockford, json.org, segue no ar como referência da especificação e como pedaço da história da web.

Por que o JSON venceu o XML

O JSON é cerca de 30–40% menor que o XML equivalente (sem tags de fechamento, sem atributos), mapeia diretamente para estruturas de dados nativas em qualquer linguagem e é analisado muito mais rápido. O XML mantém seus nichos (marcação de documentos, SOAP, configurações com schemas), mas o JSON domina a troca de dados.