Artigo escrito em setembro de 2017
JSON conquistou o mundo. Se hoje dois aplicativos se comunicam via Internet, provavelmente o fazem usando JSON. O padrão é aceito por todos os principais players: das dez APIs da Web mais populares, desenvolvidas principalmente por grandes empresas como Google, Facebook e Twitter,
apenas uma API transfere dados em XML, não em JSON. Por exemplo, o Twitter suportou XML até 2013, quando lançou uma nova versão da API exclusivamente em JSON. Entre outros desenvolvedores, o JSON também é popular: de acordo com o Stack Overflow,
mais perguntas são feitas sobre o JSON do que sobre qualquer outro formato de troca de dados .
XML ainda está vivo e muito usado. Por exemplo, nos formatos web SVG, RSS e Atom. Se o autor do aplicativo Android quiser declarar que precisa de permissão do usuário, ele fará isso no manifesto do aplicativo escrito em XML. E XML não é a única alternativa JSON: alguns desenvolvedores optam pelo YAML ou pelo Buffers de protocolo do Google. Mas esses formatos estão longe de ser tão populares quanto o JSON, que agora se tornou quase o padrão de fato para a troca de dados entre programas pela Internet.
O domínio do JSON é incrível, já que em 2005 todos estavam discutindo o potencial de "JavaScript assíncrono e XML" em vez de "JavaScript assíncrono e JSON". Obviamente, existe a possibilidade de isso não dizer nada sobre a popularidade relativa dos dois formatos, apenas o AJAX parecia uma abreviação mais atraente do que o AJAJ. Porém, embora em 2005 algumas pessoas já usassem JSON em vez de XML (poucas na verdade), você ainda se pergunta como o XML pode cair tão acentuadamente que, uma década depois, a frase "JavaScript e XML assíncrono" causa um sorriso irônico. O que aconteceu durante essa década? Como o JSON substituiu o XML em muitos aplicativos? E quem inventou esse formato de dados, do qual os engenheiros e sistemas ao redor do mundo agora dependem?
O nascimento de JSON
A primeira mensagem JSON foi enviada em abril de 2001 a partir de um computador em uma garagem perto de São Francisco. A história manteve os nomes dos envolvidos no evento: Douglas Crockford e Chip Morningstar, co-fundadores da empresa de consultoria de tecnologia State Software.
Esses dois estavam desenvolvendo aplicativos AJAX muito antes do termo AJAX aparecer. Mas o suporte a aplicativos nos navegadores não era muito bom. Eles queriam transferir dados para o aplicativo após o carregamento inicial da página, mas não encontraram uma maneira que funcionasse em todos os navegadores.
Hoje em dia é difícil acreditar, mas o Internet Explorer foi o navegador mais avançado em 2001. Desde 1999, o Internet Explorer 5 oferece suporte à forma inicial do XMLHttpRequest através do ActiveX. Crockford e Morningstar poderiam usar essa tecnologia para recuperar dados no aplicativo, mas não funcionou no Netscape 4. Portanto, tive que procurar um formato diferente que funcionasse nos dois navegadores.
A primeira mensagem JSON ficou assim:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html>
Apenas uma pequena parte da mensagem se assemelha ao JSON como o conhecemos hoje. A mensagem em si é na verdade um documento HTML com algumas linhas de JavaScript. A parte semelhante a JSON é apenas um literal JavaScript para a função
receive() .
Crockford e Morningstar decidiram abusar do quadro HTML para enviar dados. Para um quadro, você pode especificar um URL que retorne um documento HTML semelhante ao documento acima. Quando o HTML é recebido, o JavaScript é iniciado e passa o literal de volta para o aplicativo. Isso funcionou com a condição de que a proteção do navegador fosse cuidadosamente contornada para impedir que a criança acesse a janela pai: como você pode ver, Crockford e Morningstar definem explicitamente o domínio do documento. Essa técnica às vezes é chamada de quadro oculto;
costumava ser usada no final dos anos 90 antes do XMLHttpRequest normal .
O que é surpreendente na primeira postagem do JSON é que não é óbvio que esse seja o primeiro uso de um novo tipo de formato de dados. É apenas JavaScript! De fato, a ideia de usar JavaScript de tal maneira é tão simples que o próprio Crockford acredita que não foi o primeiro a fazê-lo - ele afirma que alguém no Netscape usou literais de matriz JavaScript para transmitir informações
em 1996 . A publicação em JavaScript simples não requer nenhuma análise especial. Tudo é feito pelo intérprete JavaScript.
De fato, a primeira mensagem JSON do histórico teve problemas com o intérprete. O JavaScript reserva um grande número de palavras - 64 palavras estão reservadas no ECMAScript 6 - e Crockford e Morningstar as usaram involuntariamente em sua mensagem: a palavra reservada
do como uma chave. Como o JavaScript tem tantas palavras reservadas, Crockford decidiu não evitá-las, mas simplesmente cite todas as chaves JSON. A chave entre aspas é considerada pelo interpretador JavaScript como uma sequência, para que você possa usar com segurança as palavras reservadas. É por isso que as chaves JSON ainda são citadas.
Crockford e Morningstar perceberam que o novo método pode ser usado em todos os tipos de aplicações. Eles queriam chamar o formato JSML (JavaScript Markup Language), mas a abreviação já estava ocupada com algo chamado Java Speech Markup Language. Portanto, escolhemos a Notação de objeto Javascript, ou seja, JSON. Eles começaram a oferecer o formato aos seus clientes, mas logo ficou claro que eles não corriam o risco de usar uma tecnologia desconhecida sem uma especificação oficial. Então Crockford decidiu escrevê-lo.
Em 2002, Crockford comprou o domínio
JSON.org , publicou a sintaxe JSON e um exemplo de implementação do analisador. O site ainda está funcionando, embora agora mostre um link para o padrão JSON ECMA adotado em 2013. Além de lançar o site, Crockford praticamente não fez nada para promover o JSON, mas logo houve implementações do analisador JSON em uma variedade de linguagens de programação. Inicialmente, o JSON estava claramente associado ao JavaScript, mas depois ficou claro que era adequado para a troca de dados entre pares arbitrários de idiomas.
AJAX errado
O JSON recebeu um grande empurrão em 2005. Então, um designer e desenvolvedor chamado Jesse James Garrett cunhou o termo AJAX em seu
artigo . Ele tentou enfatizar que o AJAX não é apenas uma nova tecnologia, mas “várias, à sua maneira, boas tecnologias combinadas de novas e poderosas maneiras”. Garrett chamou o AJAX de uma nova abordagem para o desenvolvimento de aplicativos da web. Em uma postagem no blog, ele descreveu como os desenvolvedores podem usar JavaScript e XMLHttpRequest para criar aplicativos mais interativos. Ele chamou o Gmail e o Flickr de exemplos de sites que dependem dos métodos AJAX.
Obviamente, "X" em AJAX significava XML. Mas nas perguntas e respostas subsequentes, Garrett chamou o JSON de uma alternativa perfeitamente aceitável. Ele escreveu que "XML é a ferramenta de troca de dados mais funcional para o cliente AJAX, mas o mesmo efeito pode ser alcançado usando a Javascript Object Notation ou qualquer formato semelhante de estruturação de dados".
Os desenvolvedores realmente descobriram que podiam facilmente usar o JSON para criar aplicativos AJAX, e muitos o escolheram em vez do XML. Ironicamente, o interesse no AJAX levou a uma explosão na popularidade do JSON. Nessa época, o JSON chamou a atenção da blogosfera.
Em 2006, Dave Weiner, um blogueiro prolífico e criador de várias tecnologias XML, como RSS e XML-RPC,
reclamou que o JSON estava reinventando o XML sem uma boa razão:
“É claro que posso escrever um procedimento para analisar [JSON], mas veja até que ponto eles foram reinventando a tecnologia: por alguma razão, o XML não é bom o suficiente para eles (pergunto-me por que). Quem criou essa paródia? Vamos encontrar uma árvore e enforcar um cara. Agora mesmo. "
É fácil entender a decepção de Weiner. XML nunca foi particularmente amado. Até o próprio Weiner
disse que não gostava de XML . Mas o XML foi projetado como um sistema universal para qualquer aplicativo que você possa imaginar. XML é, na verdade, uma metalinguagem que permite definir idiomas de domínio para aplicativos individuais - por exemplo, RSS e SOAP. Weiner acredita que é importante criar consenso para todos os benefícios que o formato comum de troca traz. Na sua opinião, a flexibilidade do XML é capaz de satisfazer qualquer necessidade. No entanto, o JSON é um formato que não oferece vantagens sobre o XML, com exceção da remoção de lixo eletrônico, que tornou o XML tão flexível.
Crockford viu o post de Weiner no blog e comentou. Em resposta à acusação de que o JSON está reinventando o XML, Crockford escreveu:
" Reinventar a
roda é bom porque você pode dar a volta" .
JSON vs XML
Em 2014, o JSON foi oficialmente reconhecido como um padrão ECMA e RFC. Ele conseguiu o seu tipo MIME. JSON entrou nas grandes ligas.
Por que o JSON se tornou muito mais popular que o XML?
No
JSON.org, Crockford lista alguns dos
benefícios do JSON sobre XML . Ele escreve que o JSON é mais fácil de entender tanto por pessoas quanto por máquinas, porque sua sintaxe é mínima e sua estrutura é previsível. Outros blogueiros
mencionam a verbosidade XML e o "imposto sobre tags". Cada marca de abertura no XML deve ter uma marca de fechamento, o que significa muitas informações redundantes. Isso torna o XML muito maior que o documento JSON equivalente, mas o mais importante é que, por causa disso, o documento XML é mais difícil de ler.
Crockford
chamou outra grande vantagem do JSON: ele foi originalmente projetado como um formato para a troca de informações estruturadas entre programas. Embora o XML tenha sido usado para o mesmo objetivo, ele foi originalmente desenvolvido como uma linguagem de marcação de documentos. Ele surgiu do SGML (Standard Generalized Markup Language), que, por sua vez, evoluiu da linguagem de marcação Scribe, destinada ao texto de marcação, como o LaTeX. Em XML, dentro de uma tag, pode haver o chamado "conteúdo misto", ou seja, texto com tags incorporadas envolvendo palavras ou frases. Assemelha-se a um editor que marca um manuscrito com um marcador vermelho ou azul, uma espécie de metáfora para a linguagem de marcação. O JSON, por outro lado, não suporta um análogo exato de conteúdo misto, o que significa simplificar a estrutura. O documento é melhor representado na forma de uma árvore, mas, abandonando a idéia do documento, Crockford conseguiu limitar o JSON a dicionários e matrizes de elementos familiares que todos os programadores usam para criar seus programas.
Finalmente, meu próprio palpite é que as pessoas não gostaram da complexidade do XML, e isso foi devido à sua diversidade. À primeira vista, é difícil distinguir entre o XML em si e suas sub-linguagens, como RSS, ATOM, SOAP ou SVG. As primeiras linhas de um documento XML típico estabelecem a versão do XML e, em seguida, a sub-linguagem específica à qual o documento XML deve corresponder. Essas são muitas opções em comparação com o JSON, que é tão simples que nenhuma nova versão da especificação JSON será gravada. Os desenvolvedores de XML, na tentativa de criar um único formato de troca de dados para tudo, foram vítimas da armadilha clássica do programador: complicação técnica excessiva. XML é tão geral que é difícil usar algo simples.
Em 2000, uma campanha começou a alinhar o HTML com o padrão XML. Publicou uma especificação para HTML compatível com XML, mais tarde conhecido como XHTML. Alguns fabricantes de navegadores começaram imediatamente a oferecer suporte ao novo padrão, mas rapidamente ficou claro que o público em geral que trabalhava com HTML não queria mudar seus hábitos. O novo padrão exigia validação XHTML mais rigorosa do que era habitual para HTML, mas muitos sites dependiam de regras HTML gratuitas. Em 2009, os ativistas pararam de tentar escrever uma segunda versão do XHTML quando ficou claro que o futuro estava no padrão HTML5, que não exigia conformidade com XML.
Se os esforços do XHTML fossem bem-sucedidos, talvez o XML se tornasse um formato de dados comum, como esperavam seus desenvolvedores. Imagine um mundo em que documentos HTML e respostas de API tenham exatamente a mesma estrutura. Nesse mundo, o JSON pode não ter se tornado tão popular como é hoje. Mas considero o fracasso do XHTML um tipo de derrota moral para o campo XML. Se o XML não ajudou o HTML, pode haver ferramentas melhores para outros aplicativos. No mundo real, é fácil entender por que o formato JSON simples e altamente especializado tem sido tão bem-sucedido.