¿Cuándo preferir JSON sobre XML?

Uso JSON a menos que se me requiera usar XML. Es más fácil de entender, y (porque requiere menos sobrecarga de configuración) es más fácil programar para leer y escribir si las bibliotecas están disponibles en su contexto, y ahora son bastante ubicuas.

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

Considerando su caso específico donde ya está haciendo javascript en el lado del cliente, yo iría con JSON por estas razones:

• Dado que JSON es nativo de javascript tendrías que escribir menos código en el del lado del cliente-Solo eval() (o, mejor aún, JSON.parse()) el JSON string and get an object you can utilizar.

• 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 más corto cadenas que XML. Usando JSON will reducir la cantidad de datos en ejecución a través del alambre y mejorar rendimiento en ese sentido.

He aquí algunas lecturas adicionales: http://www.subbu.org/blog/2006/08/json-vs-xml

Algunas otras cosas que he encontrado en el XML vs JSON relm:

JSON es muy bueno para

• pares nombre/valor)
• anidando esos pares

Lo que significa que tiende a gustar una matriz o matriz anidada. Sin embargo JSON falta ambos

• atributos
• espacio de nombres

Por lo tanto, si combina dos o más servicios JSON, podría haber conflictos potenciales de espacio de nombres. Dicho esto, JSON se puede usar para aproximadamente el 90% de las mismas cosas XML se puede utilizar para el intercambio de datos en mi experiencia.

Normalmente JSON es más compacto y más rápido de analizar.

Prefiera XML si:

• Necesita procesar los datos en el cliente, y 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 trozos de datos.
  • Un buen caso es convertir los datos en un fragmento HTML.
• Varios casos heredados:
  • Existe un servicio XML, y es una molestia reescribirlo con JSON para algunas razones.
  • Debe publicar estos datos como XML después de un procesamiento ligero utilizando la entrada del usuario.

Un caso importante de (casi) XML: intentar detectar cuándo enviar fragmentos HTML es más beneficioso que enviar datos sin procesar. AHAH puede hacer maravillas en aplicaciones simples, pero frecuentemente pasadas por alto. Por lo general, este estilo asume que un servidor envía fragmentos HTML que se insertarán en la página web sin procesamiento.

Normalmente en los casos AHAH CSS es se aprovecha al máximo para masajear fragmentos visualmente e implementar condiciones simples como ocultar / mostrar partes relevantes del fragmento utilizando configuraciones específicas del usuario o específicas de la aplicación.

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

Ya que está usando jQuery, sugiero usar JSON: jQuery puede recuperar datos JSON y convertirlos en un objeto Javascript automáticamente. De hecho, puede convertir datos JSON en un objeto Javascript usando eval. XML tendría que ser transversal manualmente por usted (no se cómo funciona esto en Javascript, pero es difícil / más molesto en la mayoría idiomas con los que he usado bibliotecas XML).

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

El análisis XML siempre consume muchos recursos del navegador y debe evitarse tanto como sea posible a menos que se requiera lo contrario.

Elegiría XML sobre JSON si necesito validar el fragmento de datos entrantes, porque XML soporta esto nativly a través de XSD.

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

En realidad creo que puede dibujar muchas similitudes entre XML y JSON comparando las diferencias entre los lenguajes dinámicos (JSON) y estáticos (XML).

Básicamente XML es un formato de serialización más estricto y rígido que puede ser opcionalmente puede verificarse con un esquema adjunto (que puede ser un XSD o un DTD). Los XSD son bastante elaborados y le permiten describir muchos tipos diferentes, por ejemplo, Fechas, Horas, Enumeraciones, Tipos definidos por el Usuario e incluso herencia de tipos, etc. SOAP se basa efectivamente en el conjunto de características XML proporcionando una forma estandarizada de describir sus servicios web (por ejemplo, tipos y operaciones) a través de un WSDL. La verbosidad y complejidad de la especificación WSDL significa que puede ser más tedioso desarrollarla con mas al mismo tiempo, hay muchas más herramientas disponibles para usted y la mayoría de los lenguajes modernos proporcionan herramientas automatizadas para generar sus proxies de cliente quitando parte de la carga al tratar de interoperar con servicios externos. (Aunque al mismo tiempo me parece que los proxies generados son una carga a sí mismos 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 su servicio web necesita ser accedido desde muchos idiomas diferentes.

Para todos sus beneficios XML viene con desventajas también. Se basa en espacios de nombres para proporcionar un formato extensible escrito y le permite especificar atributos y elementos dentro del mismo documento. Tener diferentes espacios de nombres dentro de un documento significa mucho tiempo cuando se utiliza un analizador Xml para extraer datos, también deberá proporcionar el espacio de nombres de cada elemento que desee recuperar / atravesar. También extrapola la carga útil haciéndola más detallada de lo necesario. Tener la opción de generar atributos así como elementos significa que sus clases no se asignan bien a un documento XML. Estas características por sí solas lo convierten en un mal ajuste programático para la mayoría de los idiomas, lo que hace que sea más tedioso y engorroso trabajar con él. Microsoft ha reconocido y simplificado esto un poco con en su serializador DataContract eliminando los atributos XML y simplemente teniendo las propiedades de su asignación de clase a elementos Xml solamente.

JSON, por otro lado, es completamente opuesto a XML en muchos aspectos, ya que es muy poco tipado 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 cadena. Esto no es genial cuando se trata de comunicarse a través de los límites del idioma, ya que tendrá que adherirse a alguna especificación no estándar fuera de banda si desea admitir tipos más específicos. En el lado positivo es limitado feature-set hace un buen ajuste programático a la mayoría de los lenguajes , y es perfectamente adecuado para JavaScript, ya que una cadena JSON puede ser evaluada directamente en el objeto JavaScript.

Tamaño y rendimiento

Tengo algunos puntos de referencia de la base de datos northwind disponibles comparando el tamaño y la velocidad entre las implementaciones XML y JSON de Microsofts. Básicamente XML es más de 2 veces el tamaño de JSON, pero al mismo tiempo parece que Microsoft puso un gran esfuerzo en optimizando su DataContractSerializer XML como es más del 30% más rápido que su JSON one. Parece que tienes que hacer un intercambio entre el tamaño y el rendimiento. No contento con este hecho, decidí escribir mi propio fast JsonSerializer que ahora es 2.6 x más rápido que el XML de MS - así que lo mejor de ambos mundos :).

De JSON-los últimos pies

Cuando vas por la ruta JSON, ejecutar en los mismos problemas que XML hace 10 años:

Mezcla de datos de dos fuentes diferentes en un paquete JSON puede causar elemento etiquetas para chocar entre sí. Mix up una hoja de embalaje y una factura, y de repente la dirección del Remitente puede significar algo muy diferente. Por eso XML tiene espacios de nombres.

Conversión entre diferentes JSON las estructuras requerirían escritura código mundano. Una forma más declarativa mapear datos facilitaría el trabajo. Por eso XML tiene XSLT.

Describiendo un paquete JSON estructura - sus campos, tipos de datos, sucesivamente.-es necesario para las personas para engancharte a tus servicios. Es esencial para tener un lenguaje de metadatos por esto. Por eso XML tiene Esquemas.

Llevando a cabo dos simultáneos toma de conversaciones cliente-servidor cuidado. Si le preguntas a la servidor dos preguntas y obtener una respuesta, cómo ¿sabes qué pregunta responde? Es por eso que XML tiene WS-Correlation.

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

Extensible Markup Language (XML) es un formato de texto derivado del Estándar Generalized Markup Language (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 en HTML tiene un grosor de una pulgada. Esto se debe a que el formato y la estructuración de documentos es un negocio complicado. . . .

Claramente JSON es más rápido, pero es incluso más claro que es difícil de leer. Use JSON para la velocidad, use XML si habrá interacción humana y puede sacrificar la velocidad.

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

Utilizo JSON para cualquier tipo de configuración, intercambio de datos o mensajería. Utilizo XML solo si tengo que hacerlo por otras razones o para marcar semánticamente datos similares a un documento.

Tanto XML como JSON son compatibles con Microsoft. Los literales XML fueron la nueva característica interesante en VB 9. En la próxima versión de ASP.NET 4.0 JSON es una necesidad 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.

Usando JSON

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

Usando XML

• Principalmente en un tipo de entorno SOA donde se está integrando varios servicios en plataformas y tecnologías heterogéneas.
• EL JABÓN tiene la ventaja de que se puede transmitir a través de diferentes protocolos distintos de HTTP.
• Fácil de usar en la herramienta de transformación de modelos de datos como XSLT, XSL-FO, etc.
• Gran cantidad de soporte de bases de datos para almacenar/consultar(XQuery) datos XML.
• XML es un formato de datos muy maduro, por lo que encontrará muchas herramientas para soportar cualquier caso de uso que se le ocurra.

Reglas rápidas:

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

Explicación:

El único rol de JSON es serializar datos orientados a objetos usando los tipos de datos comunes a la mayoría de los lenguajes de programación: listas, hashes , y escalares , y para ese propósito realmente no se puede superar o mejorar sobre. A saber, "JSON no tiene número de versión [como] no se anticipan revisiones a la gramática JSON". - Douglas Crockford (No se puede superar eso como una señal de que haces tu trabajo perfectamente)

XML se vendió una vez como un formato de intercambio de datos, pero tenga en cuenta los dos casos de uso más comunes: Comunicación cliente-servidor asíncrona (AJAX) - JSON prácticamente ha reemplazado XML por completo (La X debería ser realmente una J), y servicios web : JSON ha hecho que XML alternativa.

La otra cosa para la que se usó XML fue para la escritura/lectura humana(?) archivos de datos para programas, pero aquí también tienes un formato más conciso, más amigable con el programa, más amigable con los humanos 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 para lo que estaba destinado.

Encontré este artículo en digital bazaar realmente interesante.

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

Acerca de JSON pros:

Si todo lo que desea pasar son valores atómicos o listas o hashes de atomic values, JSON tiene muchas de las ventajas de XML: es directamente utilizable a través de Internet, soporta una amplia variedad de aplicaciones, es fácil escribir programas para procesar JSON, tiene pocos características opcionales, es humano-legible y razonablemente claro, su diseño es formal y conciso, los documentos JSON son fáciles de crear, y utiliza Unicode. ...

Acerca de XML pros:

XML se ocupa notablemente bien de toda la riqueza de no estructurados datos. No estoy preocupado por el futuro de XML en absoluto, incluso si su muerte se celebra alegremente por un cuadro de diseñadores de API web.

Y no puedo resistirme a meter un " Te lo dije!"token away in my Escritorio. Espero ver lo que la gente JSON hace cuando están se le pidió que desarrollara API más ricas. Cuando quieren intercambiar menos bien datos estructurados, ¿lo colocarán en JSON? Veo ocasional menciones de un lenguaje de esquema para JSON, ¿seguirán otros lenguajes? ...

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

También JSON IMHO es mucho más claro que XML, lo que lo hace para mí una clara ventaja. Y si estás trabajando con. NET, Json.NET es un claro ganador para ayudarte a trabajar con JSON.