Se você escreve código há mais de uma semana, com quase toda certeza já esbarrou no JSON. Ele aparece em todo lugar — respostas de APIs REST, arquivos de configuração, documentos de banco de dados, armazenamento do navegador, logs. Mas o que é ele exatamente, e por que virou o formato que dominou a web?
JSON significa JavaScript Object Notation. Apesar do nome, ele é completamente independente de linguagem e tem bibliotecas em todas as principais linguagens de programação. Douglas Crockford o formalizou no início dos anos 2000 como uma alternativa mais simples ao XML para comunicação entre navegador e servidor. A especificação também é padronizada como ECMA-404, e é tão pequena que cabe num cartão de visita — o que é parte do motivo de ter vencido.
Como o JSON se parece de verdade?
Aqui está um trecho de JSON que representa um objeto de usuário. Esse único exemplo cobre todos os seis tipos de dados que o JSON suporta:
{
"name": "Alice",
"age": 30,
"score": 98.5,
"active": true,
"nickname": null,
"tags": ["developer", "blogger"],
"address": {
"city": "Berlin",
"country": "Germany"
}
}Os seis tipos de dados do JSON
JSON suporta exatamente seis tipos de valores. Só isso. Essa simplicidade é uma virtude — você aprende o formato inteiro numa tarde.
{
"string": "Hello, world",
"integer": 42,
"float": 3.14159,
"boolean": true,
"nothing": null,
"array": [1, "two", false, null],
"object": { "nested": true }
}- String — Qualquer texto entre aspas duplas.
"hello","2024-01-01",""são todas strings válidas. - Number — Inteiro ou ponto flutuante. Sem distinção entre int e float. Observação:
NaNeInfinitynão são números JSON válidos. - Boolean —
trueoufalse, só em minúsculas. - Null — Representa "nenhum valor". Útil para campos opcionais que ainda não foram definidos.
- Array — Uma lista ordenada de valores. Pode misturar tipos:
[1, "two", true, null]é perfeitamente legal. - Object — Um conjunto de pares chave–valor. As chaves precisam ser strings entre aspas duplas.
Uma resposta de API do mundo real
Veja como uma resposta real de uma API REST pode ser quando você chama GET /api/users/42.
Repare como ela aninha objetos e arrays para representar dados mais ricos:
{
"id": 42,
"username": "alice_dev",
"email": "[email protected]",
"createdAt": "2023-06-15T09:30:00Z",
"preferences": {
"theme": "dark",
"notifications": true,
"language": "en"
},
"roles": ["user", "editor"],
"lastLogin": "2024-01-10T14:22:00Z",
"stats": {
"postsPublished": 27,
"commentsWritten": 154,
"likesReceived": 489
}
}Você acessaria a preferência de tema da alice_dev em JavaScript com
user.preferences.theme, ou pegaria o primeiro papel dela com user.roles[0].
Esse mapeamento natural para as primitivas da linguagem é exatamente o que faz trabalhar com JSON parecer tão tranquilo.
Regras de sintaxe do JSON — as pegadinhas que pegam todo mundo
JSON parece simples, mas tem algumas regras rígidas. Erre uma e o payload inteiro falha no parse. Esses são os erros que mais vejo:
- Chaves precisam estar entre aspas duplas.
{"name": "Alice"}é válido.{name: "Alice"}não é. Isso pega de surpresa quem vem do JavaScript, onde chaves sem aspas em objetos funcionam. - Sem vírgulas no final.
{"a": 1, "b": 2,}vai gerar erro de parse. JavaScript é tolerante aqui; a spec do JSON não é. - Sem comentários. Comentários
//ou/* */não existem em JSON. Se você precisa de arquivos de config com comentários, considere YAML ou TOML. - Sem
undefined. Oundefineddo JavaScript não existe em JSON. Usenullpara valores ausentes. - Strings precisam usar aspas duplas. Strings com aspas simples como
{'key': 'value'}são JSON inválido. - Sem zeros à esquerda.
042é inválido.42ou0.42estão ok.
Por que o JSON conquistou a web
Antes do JSON, o XML era rei. Uma resposta típica de API em XML era verbosa, exigia um parser XML de verdade, e parecia que você estava trabalhando contra a linguagem. JSON podia ser interpretado pelo JSON.parse() nativo do JavaScript — sem precisar de biblioteca. Era mais leve na rede, legível de cara, e mapeava diretamente para os objetos e arrays que os devs já usavam todo dia.
No fim dos anos 2000, a maioria das APIs públicas começou a oferecer JSON junto com XML. No começo dos anos 2010, muitas abandonaram o suporte a XML por completo. Hoje, o padrão assumido para qualquer API REST é JSON. Até o GraphQL, que substituiu o REST em muitos contextos, ainda usa JSON como formato de resposta.
O JSON também se define pelo que ele não suporta
Algumas das limitações do JSON são escolhas de design intencionais que o mantêm simples e interoperável:
- Sem tipo data. Datas são só strings. A convenção é o formato ISO 8601:
"2024-01-15T09:30:00Z". - Sem dados binários. Arquivos e imagens normalmente são codificados em Base64 dentro de uma string.
- Sem valores de função.
{"fn": function(){} }é inválido. JSON é puro dado, nunca código. - Sem chaves duplicadas. Tecnicamente permitido pela spec, mas o comportamento é indefinido. Na prática, os parsers pegam o último valor.
Ferramentas úteis para trabalhar com JSON
Aqui estão algumas ferramentas que você vai usar o tempo todo ao trabalhar com JSON: JSON Formatter para formatar respostas minificadas, JSON Validator para encontrar erros de sintaxe, JSON Minifier para comprimir JSON em produção, e JSON Path para consultar dados profundamente aninhados sem escrever loops.
A spec oficial mora em json.org e vale mesmo a leitura — leva uns 10 minutos e você entende o formato completamente. A spec formal do IETF é a RFC 8259 se você precisar resolver algum debate.
Fechando
JSON é um formato de dados leve e legível para humanos construído sobre seis tipos de valores: strings, números, booleanos, null, arrays e objetos. Tem regras de sintaxe rígidas mas nenhuma surpresa depois que você conhece. O motivo de ter se tornado onipresente não é por ser o formato mais poderoso — é por ser o mais simples que cobre 95% das necessidades reais de dados. Se você está construindo qualquer coisa ligada à web, entender JSON não é opcional. É fundamental.