¿Cuándo preferir JSON sobre XML?

Question

Mi requisito es simplemente mostrar un conjunto de valores recuperados de la base de datos en un spread. Estoy usando jquery.

Answer 1

favor XML a través de JSON cuando cualquiera de estos es cierto:

• Usted necesita validación de mensajes
• Estás usando XSLT
• Sus mensajes incluyen una gran cantidad de texto marcado
• Usted necesidad de interoperar con entornos que no son compatibles con JSON

Favorecen JSON sobre XML cuando todos estos son verdaderos:

• Los mensajes no necesitan ser validados, o validar su deserialización es simple
• No está transformando los mensajes, o la transformación de sus deserialización es simple
• Sus mensajes son en su mayoría datos, no marcada en marcha
texto
• los criterios de valoración de mensajería tienen buenas herramientas JSON

Answer 2

JSON es la codificación nativa de javascript. Debería ser mucho más rápido y fácil trabajar con él.

Answer 3

JSON es fácil y más rápido de analizar. XML es un poco más difícil de analizar, y es más lento de analizar y transferir (en la mayoría de los casos).

Dado que está utilizando jQuery, sugiero usar JSON: jQuery puede recuperar datos JSON y convertirlos en un objeto Javascript automáticamente. De hecho, puedes convert JSON data into a Javascript object using eval. XML tendría que ser cruzado manualmente por usted (no sé cómo funciona esto en Javascript, pero es difícil/más molesto en la mayoría de los lenguajes con los que he usado bibliotecas XML).

Answer 4

Uso JSON a menos que deba usar XML. Es más simple de entender, y (debido a que requiere menos sobrecarga de configuración) es más fácil programar para lectura y escritura si las bibliotecas están disponibles en su contexto, y ahora son bastante ubicuas.

Cuando Amazon expuso por primera vez sus catálogos como un servicio web, ofrecieron tanto JSON como XML. Algo así como el 90% de los implementadores eligieron JSON.

Answer 5

Utilizo JSON para cualquier tipo de configuración, intercambio de datos o mensajería. Utilizo XML solo si tengo que hacerlo por otros motivos o para marcar semánticamente datos de documentos.

Answer 6

Teniendo en cuenta el caso específico en el que ya está haciendo javascript en el lado del cliente, me gustaría ir con JSON por estas razones:

• Desde JSON es nativa de JavaScript que tendría que escribir menos código en el lado del cliente - Solo eval() (o, mejor aún, JSON.parse()) la cadena JSON y obtiene un objeto que puede usar .

• Al mismo tiempo, la evaluación de JSON en el lado del cliente será más eficiente, y por lo tanto más rápido.

• La serialización JSON produce cadenas más cortas que XML. El uso de JSON hará que reduzca la cantidad de datos que se ejecutan en a través del cable y mejore el rendimiento de en ese sentido.

aquí hay algo de lectura adicional: http://www.subbu.org/blog/2006/08/json-vs-xml

Answer 7

Por lo general, JSON es más compacto y más rápido para analizar.

Prefiero XML si:

• Es necesario para procesar los datos en el cliente, y se puede aprovechar XSL para eso. Lo más probable es que la cadena XML + XSL funcione más rápido que JSON + JavaScript, especialmente para grandes cantidades de datos.
  • Un buen caso es convertir los datos en un fragmento de HTML.
• Varios casos heredados:
  • Hay un servicio XML existente, y es una molestia para volver a escribir con JSON por algunas razones.
  • Tiene que volver a publicar esta información como XML después de un ligero procesamiento con la entrada del usuario.

Un caso importante de XML (casi): tratar de detectar cuando el envío de fragmentos de HTML es más beneficioso que el envío de datos en bruto. AHAH puede hacer maravillas en aplicaciones simples, pero a menudo se pasa por alto. Por lo general, este estilo asume que un servidor envía fragmentos de HTML que se incluirán en la página web sin procesamiento.

Por lo general, en los casos AHAH, CSS se aprovecha al máximo para hacer fragmentos de masajes visuales e implementar condicionales simples como ocultar/mostrar partes relevantes del fragmento utilizando configuraciones específicas del usuario o específicas de la aplicación.

Answer 8

Elegiría XML sobre JSON si tuviera que validar el fragmento de datos entrantes, porque XML lo admite nativamente a través de XSD.

Answer 9

algunas otras cosas que se han topado en el XML vs JSON relm:

JSON es muy bueno para

• pares nombre/valor
• anidan aquellos pares

lo que significa que tiende a recibir una matriz o matriz anidada. Sin embargo JSON le falta la

• atributos
• namespacing

lo tanto, si se va a combinar dos o más servicios JSON podría haber posibles conflictos de nombres.Dicho esto, JSON se puede usar para aproximadamente el 90% de las mismas cosas en las que se puede usar XML al intercambiar datos en mi experiencia.

Answer 10

JSON siempre es preferible en términos del procesamiento que el navegador del cliente tiene que hacer para analizar los datos. Además, JSON es un formato de intercambio de datos liviano.

El análisis XML siempre consume gran cantidad de recursos del navegador y se debe evitar tanto como podamos a menos que se requiera de otro modo.

Answer 11

Tanto XML como JSON son compatibles con Microsoft. Los literales XML fueron la nueva característica genial en VB 9. En la próxima versión de ASP.NET 4.0, JSON es imprescindible para aprovechar el poder de las plantillas del lado del cliente.

De la pregunta que ha hecho, parece que JSON podría ser la opción para usted, ya que es fácil de procesar en el lado del cliente con o sin jQuery.

Answer 12

from JSON - the last feet

Al bajar la ruta JSON, que plazo en los mismos temas que XML enfrentó hace 10 años:

datos de mezcla de dos fuentes diferentes en un paquete JSON puede causa que las etiquetas del elemento se topen entre sí. Mezcle una hoja de embalaje y una factura, y de repente la dirección De puede significar algo bastante diferente. Es por eso que XML tiene espacios de nombres.

La conversión entre diferentes estructuras JSON requerirían escribir código mundanas. Una manera más declarativa de de mapear datos facilitaría el trabajo. Es por eso que XML tiene XSLT.

Describiendo estructura-sus campos, tipos de datos de un paquete JSON, etc. -es necesaria para que la gente a enganchar en sus servicios. Es esencial tener un lenguaje de metadatos para esto. Es por eso que XML tiene Schemas.

Llevar a cabo dos conversaciones simultáneas de cliente-servidor requiere atención. Si le pregunta al servidor dos preguntas y recibe una respuesta, ¿cómo sabe que responde? Es por eso que XML tiene WS-Correlation.

Answer 13

que tienen un blog sobre el tema que detalla la historia de protocolos de Internet (es decir, SOAP, XML, JSON, REST, POX, etc.) que proporcionan un resumen, así como algunas ventajas y desventajas de cada uno: http://www.servicestack.net/mythz_blog/?p=154

Creo que puede hacer muchas similitudes entre XML y JSON al comparar las diferencias entre los lenguajes dinámico (JSON) y estático (XML).

Básicamente XML es un formato de serialización más rígido y rígido que se puede verificar opcionalmente con un esquema adjunto (que es un XSD o DTD). Los XSD son bastante elaborados y le permiten describir muchos tipos diferentes, p. Ej. Fechas, tiempos, enumeraciones, tipos definidos por el usuario e incluso tipo de herencia, etc.SOAP se basa de forma efectiva en la parte superior del conjunto de características XML, proporcionando una forma estandarizada para describir sus servicios web (por ejemplo, tipos y operaciones) a través de un WSDL. La verbosidad y la complejidad de la especificación WSDL significa que puede ser más tedioso desarrollar con, pero al mismo tiempo, hay muchas más herramientas disponibles para usted y la mayoría de los idiomas modernos proporcionan herramientas automatizadas para generar proxies de sus clientes, llevando algo de la carga apagado cuando se trata de interoperar con servicios externos. (Aunque, al mismo tiempo, considero que los proxies generados son una carga para ellos cuando se trata de servicios web que cambian con frecuencia).

Todavía recomendaría usar XML para sus servicios web si tiene un "servicio empresarial" bien definido que no está sujeto a cambios frecuentes o se debe acceder a su servicio web desde muchos idiomas diferentes.

Para todos sus beneficios, XML también viene con inconvenientes. Se basa en espacios de nombres para proporcionar un formato extensible y permite especificar atributos y elementos dentro del mismo documento. Tener diferentes espacios de nombres dentro de un documento significa una gran cantidad de tiempo cuando se utiliza un analizador Xml para extraer datos, también deberá proporcionar el espacio de nombres de cada elemento que desea recuperar/atravesar. También extrapola la carga útil por lo que es más detallado de lo que necesita ser. Tener la opción de generar atributos y elementos significa que las clases no se asignan correctamente a un documento XML. Estas características por sí mismas lo convierten en un ajuste programático deficiente para la mayoría de los idiomas, por lo que es más tedioso y engorroso trabajar con él. Microsoft lo ha reconocido y simplificado un poco con su serializador DataContract al eliminar los atributos XML y simplemente tener las propiedades de su mapa de clase solo para los elementos Xml.

JSON por el contrario es completamente opuesto a XML en muchos sentidos, ya que es muy poco tipeado y solo tiene soporte simple para tipos básicos: Number, Bool, string, Objects y Arrays. Todo lo demás esencialmente tiene que caber en una cuerda. Esto no es genial cuando intenta comunicarse a través de límites de idioma, ya que tendrá que cumplir algunas especificaciones no estándar fuera de banda si desea admitir tipos más específicos. Por el lado positivo, su conjunto limitado de funciones tiene un buen ajuste programático para la mayoría de los idiomas, y es perfectamente adecuado para JavaScript, ya que una cadena JSON puede ser evaluada directamente en el objeto JavaScript.

tamaño y rendimiento

que tienen algún northwind database benchmarks available comparando el tamaño y la velocidad entre Microsoft de XML y JSON implementaciones. Básicamente, XML es más de 2 veces el tamaño de JSON, pero al mismo tiempo parece que Microsoft se esforzó mucho para optimizar su DataContractSerializer XML como , es más de un 30% más rápido que su JSON. Parece que tienes que hacer concesiones entre el tamaño y el rendimiento. No estoy contento con este hecho, decidí escribir mi propio rápido JsonSerializer que ahora es 2.6 veces más rápido que el XML de MS, así que lo mejor de ambos mundos :).

Answer 14

Utilizando JSON

• Si los datos son para ser consumidos por el JavaScript en el navegador.
• El modelo de datos es simple y no complejo (demasiados objetos compuestos).

uso de XML

• Sobre todo en un tipo SOA del entorno en el que está integrando varios servicios sobre plataformas y tecnologías heterogéneas.
• SOAP tiene la ventaja de que se puede transmitir a través de diferentes protocolos distintos de HTTP.
• Fácil de usar en herramienta de transformación de modelo de datos como XSLT, XSL-FO etc.
• Lote de soporte de base de datos para almacenar/consultar (XQuery) datos XML.
• XML es un formato de datos muy maduro, por lo que encontrará muchas herramientas para respaldar cualquier caso de uso que se le ocurra.

Answer 15

Encontré this article at digital bazaar realmente interesante.

Algunas partes del artículo se citan a continuación.

Sobre pros JSON:

Si todo lo que desea pasar alrededor son valores atómicos o listas o hashes de valores atómicos, JSON tiene muchas de las ventajas de XML: es directamente utilizable 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 los humanos y razonablemente clara, su diseño es formal y conciso, los documentos JSON son fáciles de crear y usa Unicode. ...

sobre XML pros:

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

Y no puedo resistir meterme un "¡Te lo dije!" token en mi escritorio . Espero con ansia ver lo que hacen las personas de JSON cuando están para desarrollar API más ricas. Cuando quieran intercambiar menos datos estructurados, ¿lo calzarán en JSON? Veo ocasionalmente menciones de de un lenguaje de esquema para JSON, ¿seguirán otros idiomas? ...

Answer 16

reglas rápidos:

• JSON: Formato de datos programa a programa
• YAML (JSON superconjunto): formato de datos de humano a programa
• XML: formato de marcado de documento

Explicación:

única función de JSON es serializar datos orientada a objetos utilizando los tipos de datos comunes a la mayoría de los lenguajes de programación: listas, hashes, y escalares, y para ello se realmente no se puede vencer ni mejorar.A saber "JSON no tiene número de versión [como] no se prevén revisiones a la gramática JSON". - Douglas Crockford (no se puede superar eso como una señal de que usted haga su trabajo a la perfección)

XML una vez que se vendió como un formato de datos entre el cambio, pero hay que considerar los dos casos de uso más comunes: comunicación cliente-servidor asíncrono (AJAX) - JSON ha reemplazado prácticamente por completo XML (la X debería ser realmente una J), y servicios web: JSON ha convertido XML en una alternativa redundante.

La otra cosa XML se usaba ampliamente para los archivos de datos editables/legibles (?) Para programas, pero también aquí hay un formato más conciso, más amigable para el programa y más humano en YAML, un superconjunto JSON .

Por lo tanto, para la representación de datos, JSON supera a XML en todos los ámbitos. ¿Qué queda para XML entonces? Representación de documentos de contenido mixto, que es lo que was intended for.

Answer 17

Desde la primera línea en http://json.org/xml.html

Extensible Markup Language (XML) es un formato de texto derivado del lenguaje de marcado generalizado estándar (SGML). Comparado con SGML, XML es simple. El lenguaje de marcado de hipertexto (HTML), en comparación, es aún más simple. Aun así, un buen libro de referencia sobre HTML tiene un grosor de una pulgada. Esto se debe a que el formateo y la estructuración de los documentos es un asunto complicado. . . .

Clearly JSON es más rápido, pero es aún más claro que es difícil de leer. Usa JSON para velocidad, usa XML si hay interacción humana y puedes sacrificar la velocidad.

Answer 18

La mayoría de las tecnologías web más nuevas funcionan con JSON, por lo que definitivamente es una buena razón para usar JSON. Una gran ventaja es que en XML puede representar de diferentes maneras la misma información, que en JSON es más directa.

También JSON en mi humilde opinión es mucho más claro que XML, lo que me da una clara ventaja. Y si está trabajando con .NET, Json.NET es un ganador claro para ayudarlo a trabajar con JSON.