Comparação JSON e XML [fechada]

Quero saber o que é mais rápido: XML e JSON? Quando usar qual?

Antes de responder quando usar qual, um pouco de fundo:

edit: devo mencionar que essa comparação é realmente da perspectiva de usá-los em um navegador com JavaScript. Não é assim que qualquer formato de dados deve ser usado, e há muitos analisadores bons que alterarão os detalhes para tornar o que estou dizendo não muito válido.

O JSON é mais compacto e (na minha opinião) mais legível - na transmissão, pode ser "mais rápido" simplesmente porque menos dados são transferidos.

Na análise, isso depende do seu analisador. Um analisador que transforma o código (JSON ou XML) em uma estrutura de dados (como um mapa) pode se beneficiar da natureza estrita do XML ( os esquemas XML desambiguam bastante a estrutura de dados) - no entanto, no JSON, o tipo de um item (String / Número / Objeto JSON aninhado) pode ser inferido sintaticamente, por exemplo:

myJSON = {"age" : 12,
          "name" : "Danielle"}

O analisador não precisa ser inteligente o suficiente para perceber que 12representa um número (e Danielleé uma sequência como qualquer outra). Então, em javascript, podemos fazer:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

Em XML, teríamos que fazer algo como o seguinte:

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(como um aparte, isso ilustra o ponto em que o XML é bastante mais detalhado; uma preocupação com a transmissão de dados). Para usar esses dados, executá-los-ia através de um analisador, e precisaríamos chamar algo como:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

Na verdade, um bom analisador pode muito bem digitar o código agepara você (por outro lado, você pode não querer). O que está acontecendo quando acessamos esses dados é que, em vez de fazer uma pesquisa de atributo como no exemplo JSON acima, estamos fazendo uma pesquisa de mapa na chave name. Pode ser mais intuitivo formar o XML assim:

<person name="Danielle" age="12" />

Mas ainda teríamos que fazer pesquisas de mapa para acessar nossos dados:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

EDIT: Original:

Na maioria das linguagens de programação (nem todas, de maneira alguma), uma pesquisa de mapa como essa será mais cara que uma pesquisa de atributo (como chegamos acima quando analisamos o JSON).

Isso é enganoso: lembre-se de que no JavaScript (e em outras linguagens dinâmicas) não há diferença entre uma pesquisa de mapa e uma pesquisa de campo. De fato, uma pesquisa de campo é apenas uma pesquisa de mapa.

Se você deseja uma comparação realmente válida, o melhor é fazer uma comparação - faça as comparações no contexto em que você planeja usar os dados.

Enquanto eu estava digitando, Felix Kling já apresentou uma resposta bastante sucinta comparando-as em termos de quando usar cada uma delas, então não vou mais adiante.

Mais rápido não é um atributo de JSON ou XML ou um resultado que uma comparação entre eles produziria. Se houver, é um atributo dos analisadores ou da largura de banda com a qual você transmite os dados.

Aqui está (o início de) uma lista de vantagens e desvantagens de JSON e XML:

JSON

Pró:

• Sintaxe simples, que resulta em menos sobrecarga de "marcação" em comparação com XML.
• Fácil de usar com JavaScript, a marcação é um subconjunto da notação literal de objeto JS e possui os mesmos tipos de dados básicos que o JavaScript.
• Esquema JSON para descrição e tipo de dados e validação de estrutura
• JsonPath para extrair informações em estruturas profundamente aninhadas

Vigarista:

• Sintaxe simples, apenas alguns tipos de dados diferentes são suportados.

• Não há suporte para comentários.

XML

Pró:

• Marcação generalizada; é possível criar "dialetos" para qualquer tipo de finalidade
• Esquema XML para tipo de dados, validação de estrutura. Também é possível criar novos tipos de dados
• XSLT para transformação em diferentes formatos de saída
• XPath / XQuery para extrair informações em estruturas profundamente aninhadas
• suporte embutido para namespaces

Vigarista:

• Relativamente prolixo comparado ao JSON (resulta em mais dados para a mesma quantidade de informações).

Então, no final, você precisa decidir o que precisa . Obviamente, ambos os formatos têm seus casos de uso legítimos. Se você vai usar o JavaScript principalmente, deve usar o JSON.

Por favor, sinta-se livre para adicionar prós e contras. Eu não sou um especialista em XML;)

A velocidade de processamento pode não ser o único assunto relevante; no entanto, como é a questão, aqui estão alguns números em uma referência: JSON x XML: alguns números concretos sobre verbosidade . Para a velocidade, neste benchmark simples, o XML apresenta uma sobrecarga de 21% sobre o JSON.

Uma observação importante sobre a verbosidade, que é como o artigo diz, a queixa mais comum: isso não é tão relevante na prática (nem os dados XML nem JSON são normalmente tratados por humanos, mas por máquinas), mesmo que por questões de velocidade, requer algum tempo razoável para comprimir.

Além disso, neste benchmark, uma grande quantidade de dados foi processada e um aplicativo Web típico não transmitirá blocos de dados de tamanhos tão grandes quanto 90 MB e a compactação pode não ser benéfica (para blocos de dados pequenos o suficiente, um bloco compactado será maior que o bloco não compactado), portanto não aplicável.

Ainda assim, se nenhuma compactação estiver envolvida, o JSON, como obviamente terser, pesará menos no canal de transmissão, especialmente se transmitido por uma conexão WebSocket, onde a ausência da sobrecarga HTTP clássica pode fazer a diferença na vantagem do JSON, ainda mais significativo.

Após a transmissão, os dados devem ser consumidos, e isso conta no tempo total de processamento. Se dados grandes ou complexos forem transmitidos, a falta de um esquema verificado automaticamente por um analisador XML de validação pode exigir mais verificação nos dados JSON; essas verificações precisariam ser executadas em JavaScript, que não é conhecido por ser particularmente rápido e, portanto, podem apresentar uma sobrecarga adicional sobre XML nesses casos.

De qualquer forma, apenas o teste fornecerá a resposta para seu caso de uso específico (se a velocidade for realmente o único problema, e não for padrão, nem segurança, nem integridade ...).

Atualização 1: vale mencionar, é o EXI, o formato XML binário, que oferece compactação a um custo menor do que o uso do Gzip, e salva o processamento necessário para descompactar o XML compactado. EXI é XML, o que BSON é JSON. Tenha uma rápida visão geral aqui, com alguma referência à eficiência no espaço e no tempo: EXI: O último padrão binário? .

Atualização 2: também existem relatórios binários de desempenho XML, conduzidos pelo W3C, como eficiência e pouca memória e espaço na CPU, também são um problema para a área XML: Avaliação Eficiente de Intercâmbio XML .

Atualização 2015-03-01

Vale a pena notar neste contexto, pois a sobrecarga do HTTP foi levantada como um problema: a IANA registrou a codificação EXI (o XML binário eficiente mencionado acima), como uma codificação de conteúdo para o protocolo HTTP (juntamente com compress , deflate e gzip ) . Isso significa que EXI é uma opção que pode ser esperada para ser entendida pelos navegadores entre possivelmente outros clientes HTTP. Consulte Parâmetros do protocolo de transferência de hipertexto (iana.org) .

Encontrei este artigo no bazar digital realmente interessante. Citando suas citações da norma:

Sobre os profissionais JSON:

Se tudo o que você deseja transmitir são valores atômicos ou listas ou hashes de valores atômicos, o JSON tem muitas das vantagens do XML: é diretamente utilizável na Internet, suporta uma ampla variedade de aplicativos, é fácil escrever programas para processar o JSON, possui poucos recursos opcionais, é legível por humanos e razoavelmente claro, seu design é formal e conciso, os documentos JSON são fáceis de criar e usa Unicode. ...

Sobre profissionais de XML:

O XML lida notavelmente bem com a riqueza total de dados não estruturados. Não estou preocupado com o futuro do XML, mesmo que sua morte seja comemorada com alegria por um grupo de designers de APIs da web.

E eu não resisto a colocar um "eu te disse!" token na minha mesa. Estou ansioso para ver o que as pessoas JSON fazem quando são solicitadas a desenvolver APIs mais ricas. Quando eles querem trocar dados menos estruturados, eles os colocam no JSON? Vejo menções ocasionais de uma linguagem de esquema para JSON. Outras linguagens seguirão? ...

Eu pessoalmente concordo com a norma. Eu acho que a maioria dos ataques ao XML vem de desenvolvedores da Web para aplicativos típicos, e não de desenvolvedores de integração. Mas essa é a minha opinião! ;)

O XML (linguagem de marcação extensível) é usado frequentemente XHR, porque é uma linguagem de transmissão padrão, que pode ser usada por qualquer linguagem de programação e suportada no servidor e no cliente, portanto, essa é a solução mais flexível. O XML pode ser separado para mais partes, para que um grupo especificado possa desenvolver a parte do programa, sem afetar as outras partes. O formato XML também pode ser determinado pelo XML DTD ou XML Schema (XSL) e pode ser testado.

O JSON, um formato de troca de dados que está ficando mais popular como o formato possível dos aplicativos JavaScript. Basicamente, esta é uma matriz de notação de objeto. O JSON tem uma sintaxe muito simples e pode ser facilmente aprendida. E também o suporte a JavaScript que analisa JSON com a evalfunção Por outro lado, a evalfunção tem negativos. Por exemplo, o programa pode ser muito lento ao analisar JSON e, devido à segurança doeval pode ser muito arriscado. Isso não significa que o JSON não seja bom, apenas temos que ter mais cuidado.

Minha sugestão é que você use JSON para aplicativos com pouca troca de dados, como jogos. Como você não precisa se preocupar com o processamento de dados, isso é muito simples e rápido.

O XML é melhor para sites maiores, por exemplo, sites de compras ou algo parecido. O XML pode ser mais seguro e claro. Você pode criar estrutura de dados e esquema básicos para testar facilmente a correção e separá-la em partes facilmente.

Eu sugiro que você use XML devido à velocidade e segurança, mas JSON para coisas leves.

O importante sobre o JSON é manter a transferência de dados criptografada por motivos de segurança. Sem dúvida, o JSON é muito mais rápido que o XML. Eu vi o XML levar 100ms, enquanto o JSON levou apenas 60ms. Os dados JSON são fáceis de manipular.