xml - español - rest vs soap

Comparación de JSON y XML

Question

Quiero saber cuál es más rápido: XML y JSON? ¿Cuándo usar cuál?

Answer 1

Antes de contestar cuándo usar cuál, un poco de fondo:

Edición: Debo mencionar que esta comparación es realmente desde la perspectiva de usarlos en un navegador con JavaScript. No es la forma en que se debe utilizar ninguno de los formatos de datos, y hay muchos buenos analizadores que cambiarán los detalles para hacer que lo que digo no sea del todo válido.

JSON es a la vez más compacto y (en mi opinión) más legible: en la transmisión puede ser "más rápido" simplemente porque se transfieren menos datos.

En el análisis, depende de su analizador. Un analizador que convierte el código (ya sea JSON o XML) en una estructura de datos (como un mapa) puede beneficiarse de la naturaleza estricta de XML (los esquemas XML desambiguan bien la estructura de los datos). Número / Objeto JSON anidado) se puede inferir sintácticamente, por ejemplo:

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

El analizador no necesita ser lo suficientemente inteligente como para darse cuenta de que 12 representa un número (y Danielle es una cadena como cualquier otra). Así que en javascript podemos hacer:

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

En XML tendríamos que hacer algo como lo siguiente:

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

(aparte, esto ilustra el punto de que XML es bastante más detallado; una preocupación por la transmisión de datos). Para usar esta información, la ejecutaríamos a través de un analizador, luego tendríamos que llamar 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

En realidad, un buen analizador podría escribir la age para usted (por otro lado, es posible que no quiera que lo haga). Lo que sucede cuando accedemos a estos datos es que, en lugar de hacer una búsqueda de atributos como en el ejemplo JSON anterior, estamos haciendo una búsqueda en el name la clave. Podría ser más intuitivo configurar el XML de esta manera:

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

Pero todavía tendríamos que hacer búsquedas de mapas para acceder a nuestros datos:

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

EDITAR: Original:

En la mayoría de los lenguajes de programación (no todos, por cualquier extensión), una búsqueda de mapas como esta será más costosa que una búsqueda de atributos (como la que obtuvimos al analizar JSON).

Esto es engañoso: recuerde que en JavaScript (y otros idiomas dinámicos) no hay diferencia entre una búsqueda en el mapa y una búsqueda en el campo. De hecho, una búsqueda de campo es solo una búsqueda de mapa.

Si desea una comparación que realmente valga la pena, lo mejor es hacer una evaluación comparativa: realice las pruebas comparativas en el contexto en el que planea usar los datos.

Como he estado escribiendo, Felix Kling ya ha dado una respuesta bastante breve comparándolos en términos de cuándo usar cada uno, así que no seguiré adelante.

Answer 2

El XML (lenguaje de marcado extensible) se usa con frecuencia XHR porque es un lenguaje de transmisión estándar, lo que puede ser usado por cualquier lenguaje de programación, y es compatible con el lado del servidor y del cliente, por lo que esta es la solución más flexible. El XML se puede separar por más partes para que un grupo específico pueda desarrollar la parte del programa, sin afectar a las otras partes. El formato XML también puede ser determinado por el DTD de XML o el Esquema XML (XSL) y puede probarse.

El JSON es un formato de intercambio de datos que se está volviendo más popular como posible formato de las aplicaciones JavaScript. Básicamente esta es una matriz de notación de objetos. JSON tiene una sintaxis muy simple por lo que se puede aprender fácilmente. Y también el soporte de JavaScript para analizar JSON con la función eval . Por otro lado, la función eval tiene negativos. Por ejemplo, el programa puede ser muy lento al analizar JSON y, por eval de seguridad, la eval puede ser muy arriesgada. Esto no significa que el JSON no sea bueno, solo tenemos que ser más cuidadosos.

Mi sugerencia es que debería usar JSON para aplicaciones con intercambio de datos livianos, como juegos. Debido a que no tiene que preocuparse realmente por el procesamiento de datos, esto es muy simple y rápido.

El XML es mejor para los sitios web más grandes, por ejemplo, sitios de compras o algo así. El XML puede ser más seguro y claro. Puede crear una estructura de datos básica y un esquema para probar fácilmente la corrección y separarla en partes fácilmente.

Le sugiero que use XML debido a la velocidad y la seguridad, pero JSON para cosas ligeras.

Answer 3

Encontré este artículo en el bazar digital realmente interesante. Citando sus citas de Norma:

Acerca de los profesionales de JSON:

Si todo lo que quiere transmitir son valores atómicos o listas o hashes de valores atómicos, JSON tiene muchas de las ventajas de XML: es fácil de usar a través de Internet, admite una amplia variedad de aplicaciones, es fácil escribir programas para procesar JSON, tiene pocas características opcionales, es legible para el ser humano y es razonablemente claro, su diseño es formal y conciso, los documentos JSON son fáciles de crear y utiliza Unicode. ...

Acerca de los profesionales de XML:

XML trata notablemente bien con la riqueza completa de los datos no estructurados. No estoy preocupado por el futuro de XML, incluso si su muerte es celebrada alegremente por un grupo de diseñadores de API web.

Y no puedo resistirme a meter un "Te lo dije!" token de distancia en mi escritorio. Espero ver lo que hace la gente de JSON cuando se les pide que desarrollen API más ricas. Cuando quieran intercambiar datos menos estructurados, ¿lo harán en JSON? Veo menciones ocasionales de un lenguaje de esquema para JSON, ¿seguirán otros idiomas? ...

Personalmente estoy de acuerdo con la Norma. Creo que la mayoría de los ataques a XML provienen de desarrolladores web para aplicaciones típicas, y no realmente de desarrolladores de integración. ¡Pero esa es mi opinión! ;)

Answer 4

La velocidad de procesamiento puede no ser el único asunto relevante, sin embargo, como esa es la pregunta, aquí hay algunos números en un punto de referencia: JSON frente a XML: Algunos números importantes sobre la verbosidad . Para la velocidad, en este simple punto de referencia, XML presenta una sobrecarga del 21% sobre JSON.

Una nota importante sobre la verbosidad, que es como se dice en el artículo, es la queja más común: esto no es tan relevante en la práctica (ni los datos XML ni JSON son manejados normalmente por humanos, sino por máquinas), incluso si se trata de velocidad, requiere un poco más de tiempo razonable para comprimir.

Además, en este punto de referencia, se procesó una gran cantidad de datos, y una aplicación web típica no transmitirá fragmentos de datos de tales tamaños, tan grandes como 90 MB, y la compresión puede no ser beneficiosa (para fragmentos de datos lo suficientemente pequeños, una porción comprimida será más grande que el trozo sin comprimir), por lo que no es aplicable.

Aún así, si no hay compresión involucrada, JSON, como obviamente terser, pesará menos sobre el canal de transmisión, especialmente si se transmite a través de una conexión WebSocket, donde la ausencia de la sobrecarga de HTTP clásica puede hacer la diferencia en la ventaja de JSON, incluso más significativo.

Después de la transmisión, se deben consumir los datos, y esto cuenta en el tiempo total de procesamiento. Si se deben transmitir datos lo suficientemente grandes o complejos, la falta de un esquema comprobado automáticamente por un analizador XML de validación, puede requerir una mayor verificación de los datos JSON; estas verificaciones deberían ejecutarse en JavaScript, que no se sabe que sea particularmente rápido, por lo que puede presentar una sobrecarga adicional sobre XML en tales casos.

De todos modos, solo las pruebas proporcionarán la respuesta para su caso de uso particular (si la velocidad es realmente lo único, y no es estándar ni seguridad ni integridad ...).

Actualización 1: vale la pena mencionar, es EXI, el formato XML binario, que ofrece compresión a un costo menor que usar Gzip, y guarda el procesamiento necesario para descomprimir el XML comprimido. EXI es para XML, lo que BSON es para JSON. Tenga una visión general rápida aquí, con alguna referencia a la eficiencia tanto en espacio como en tiempo: EXI: ¿El último estándar binario? .

Actualización 2: también existe un informe de rendimiento XML binario, realizado por el W3C, ya que la eficiencia y el bajo consumo de memoria y memoria, también es un tema para el área XML: Evaluación eficiente del intercambio de XML .

Actualización 2015-03-01

Cabe destacar en este contexto, ya que la sobrecarga de HTTP se planteó como un problema: la IANA ha registrado la codificación EXI (el eficiente XML binario mencionado anteriormente), como una Codificación de contenido para el protocolo HTTP (junto con la compresión , deflate y gzip ) . Esto significa que EXI es una opción que se puede esperar que los exploradores entiendan entre otros posibles clientes HTTP. Ver Parámetros del Protocolo de Transferencia de Hipertexto (iana.org) .

Answer 5

Lo importante de JSON es mantener la transferencia de datos cifrada por razones de seguridad. No hay duda de que JSON es mucho más rápido que XML. He visto XML tomar 100 ms, mientras que JSON solo tomó 60 ms. Los datos JSON son fáciles de manipular.

Answer 6

Más rápido no es un atributo de JSON o XML o un resultado que una comparación entre ellos daría. Si hay alguno, entonces es un atributo de los analizadores o del ancho de banda con el que transmite los datos.

Aquí está (el comienzo de) una lista de ventajas y desventajas de JSON y XML:

JSON

Pro:

• Sintaxis simple, que resulta en menos gastos de "marcado" en comparación con XML.
• Fácil de usar con JavaScript, ya que el marcado es un subconjunto de la notación literal del objeto JS y tiene los mismos tipos de datos básicos que JavaScript.
• Esquema JSON para descripción y tipo de datos y validación de estructura
• JsonPath para extraer información en estructuras profundamente anidadas

Estafa:

• Sintaxis simple, solo se admiten unos pocos tipos de datos diferentes.

• No hay soporte para comentarios.

XML

Pro:

• Marcado generalizado; Es posible crear "dialectos" para cualquier tipo de propósito.
• Esquema XML para tipo de datos, validación de estructuras. Posibilita también la creación de nuevos tipos de datos.
• XSLT para la transformación en diferentes formatos de salida.
• XPath / XQuery para extraer información en estructuras profundamente anidadas
• construido en soporte para espacios de nombres

Estafa:

• Relativamente wordy comparado con JSON (resulta en más datos para la misma cantidad de información).

Así que al final tienes que decidir lo que necesitas . Obviamente ambos formatos tienen sus casos de uso legítimos. Si vas a usar JavaScript, deberías usar JSON.

Por favor, siéntase libre de agregar pros y contras. No soy un experto en XML;)