JSON vs XML

Origens: uma linguagem de marcação versus um formato de dados

O ancestral do XML é o SGML, e seu objetivo de design era marcar documentos: prosa que mistura parágrafos, ênfase e estrutura. É por isso que o XML, sozinho entre os dois, suporta conteúdo misto — texto com marcação inline como <title>Learning <em>XML</em></title> — e por isso ganhou atributos, referências a entidades e um modelo de processamento pesado. O JSON foi extraído dos literais de objeto do JavaScript por volta de 2001 com um único propósito: mover dados estruturados entre programas com a menor gramática possível. No JSON não há conteúdo misto, nem maquinaria de entidades, nem árvore de documento — objetos, arrays e quatro tipos escalares são o universo inteiro.

Sintaxe: o imposto das tags, atributos e o array que falta

Todo elemento XML abre e fecha, então um valor simples custa duas tags: <price>19.99</price>. O XML oferece uma grafia alternativa — <price currency="EUR">19.99</price> — e a escolha entre atributo e elemento gera debate há duas décadas sem uma resposta universal. O JSON tem exatamente uma grafia para um par chave/valor e uma para uma lista. O mais importante: o JSON tem arrays nativos; o XML não tem tipo de array algum. Uma lista é expressa repetindo um elemento, o que significa que toda ferramenta de JSON para XML precisa concordar com uma convenção para nomear e agrupar itens repetidos.

Schemas e namespaces: onde o XML ainda se justifica

O XSD é a vantagem discreta do XML nas empresas: uma linguagem de schema madura, com tipos derivados, restrições de cardinalidade, facetas de padrão e duas décadas de ferramentas capazes de validar um documento e relatar com precisão qual elemento violou qual regra. O JSON Schema persegue o mesmo objetivo com outra forma — é expressivo, suporta lógica condicional e se tornou a linguagem de contrato de facto para APIs modernas — mas sua longa história de rascunhos faz as ferramentas variarem mais no que aceitam. Os dois ecossistemas podem ser estritos; o do XML é simplesmente mais antigo.

Os namespaces são o outro trunfo duradouro do XML. Uma página XHTML pode incorporar SVG e MathML sem colisões de chaves porque cada vocabulário carrega seu próprio URI. O JSON não tem mecanismo equivalente — colisões de nomes são evitadas por convenção, ou por designs em camadas, como o JSON-LD, que anexam contexto explicitamente.

Tamanho, streaming e quando escolher cada um

Para os mesmos dados, payloads XML costumam ser maiores: só as tags de fechamento praticamente dobram a marcação dos elementos, e estilos cheios de atributos acrescentam mais ainda. Os dois formatos comprimem bem com gzip — a redundância do XML é altamente compressível — mas a sobrecarga base raramente desaparece por completo. Em streaming, o ecossistema de parsers do XML é mais profundo: os parsers push SAX e StAX foram projetados para documentos grandes demais para a memória, e toda plataforma traz um. Existem parsers de streaming para JSON, e são excelentes, mas o parse do documento inteiro continua sendo o padrão comum.

Escolha JSON para tudo que um par de programas troca: APIs web e móveis, logs estruturados, payloads entre serviços. Escolha XML quando uma especificação exigir — stacks SOAP, pipelines de publicação, formatos do Office, muitos padrões de saúde e finanças — ou quando você precisar de validação XSD e namespaces na transmissão. A orientação se inverte com clareza: JSON que vaza para um pipeline de documentos geralmente quer ser XML, e uma API da era SOAP que passa a expor JSON limpo é uma vitória de migração, não uma traição.