XML precede JSON por quase uma decada e foi a escolha padrao para servicos web (SOAP, RSS, a maioria da integracao corporativa) durante os anos 2000. JSON nao o superou em capacidade, XML pode representar qualquer coisa que JSON pode e mais; ele ganhou em peso e direto para o trabalho especifico de mover dados entre um servidor e um cliente.
Os mesmos dados, duas formas
<user>
<name>Ada Lovelace</name>
<age>36</age>
<active>true</active>
<skills>
<skill>mathematics</skill>
<skill>writing</skill>
</skills>
</user>
{
"user": {
"name": "Ada Lovelace",
"age": 36,
"active": true,
"skills": ["mathematics", "writing"]
}
}
A versao XML precisa de uma tag de fechamento para cada abertura, e um
elemento <skill> repetido para representar uma lista, porque XML nao tem sintaxe
nativa de array; um elemento <skills> com varios filhos <skill> poderia ser
facilmente um unico filho <skill>, e apenas um esquema ou convencao diz ao
leitor qual e. Os [ ] de JSON dizem “lista” de forma inequivoca em dois caracteres.
Onde XML ainda ganha
Atributos ao lado do conteudo. <price currency="USD">42.00</price>
anexa metadados a um valor sem inventar um objeto contenedor. JSON nao tem
conceito de atributo; os mesmos dados se tornam {"price": {"value": 42.00, "currency": "USD"}} ou uma convencao como uma chave @currency, ambas menos
diretas que a sintaxe nativa de XML para exatamente essa forma.
Conteudo misto. Um paragrafo de texto com marcacao embutida, <p>Some <b>bold</b> text</p>, e a forca nativa de XML, e por isso que formatos de documento
(DocBook, a maioria dos pipelines de publicacao, SVG) ainda o usam. JSON nao tem
forma de entrelacar texto e marcacao; representar um documento rico em
JSON geralmente significa uma arvore de nos tipados, o que e mais codigo para escrever e
ler do que a marcacao que XML ja lhe da gratuitamente.
Espacos de nomes e esquemas estritos. XML Schema (XSD) e espacos de nomes permitem que uma grande organizacao misture vocabularios de diferentes fontes em um documento sem colisoes de nomes, com ferramentas que existem ha mais de vinte anos. JSON Schema existe e faz trabalho real (o Gerador de JSON Schema infere um a partir de um documento real), mas e mais jovem e menos universalmente implantado que o XSD em grandes sistemas corporativos.
Onde JSON ganha, que e a maioria das APIs
Peso. Sem tags de fechamento significa menos para transmitir e menos para analisar para os mesmos dados, frequentemente com uma margem ampla em documentos profundamente aninhados.
Correspondencia direta as proprias estruturas de dados de um programa. JSON.parse em
JavaScript, ou um equivalente em uma linha em quase todas as outras linguagens,
transforma um documento JSON nos tipos nativos de objeto e array dessa linguagem
sem modelo intermediario. XML precisa de um DOM, ou uma classe gerada por esquema,
entre o texto e os dados que um programa realmente usa.
Sem perguntas de tipagem implicita. Todo valor XML e texto ate que algo
externo (um esquema, uma convencao) diga o contrario; <age>36</age> e uma
string contendo “36” a menos que seja dito para ser um numero. Os tipos number, boolean,
e null de JSON sao explicitos na propria sintaxe, entao nao ha nada a
configurar ou adivinhar.
Na pratica
Novas APIs REST sao definidas para JSON quase sem excecao hoje. XML persiste onde suas proprias forcas sao essenciais: servicos SOAP em sistemas corporativos mais antigos, feeds RSS e Atom, SVG e outros formatos nativos de marcacao, e onde atributos ou conteudo misto sao a forma real dos dados em vez de um encaixe awkward.
Convertendo entre eles
O Conversor JSON para XML funciona nas duas direcoes,
com controles para prefixos de espacos de nomes e se um valor dado se torna um
atributo XML ou um elemento filho, ja que essa escolha nao tem uma unica resposta
correta e depende do que esta consumindo a saida. Ele usa o DOMParser do navegador
para ler XML em vez de um analisador feito a mao, e cada
valor volta como uma string na entrada, o que a ferramenta indica em vez de
adivinhar silenciosamente tipos que o XML nao carrega.