Respuestas:
Favorezca XML sobre JSON cuando cualquiera de estos sea cierto:
Favorezca JSON sobre XML cuando todo esto sea cierto:
Yo uso JSON a menos que se requiera que use XML. Es más fácil de entender y (debido a que 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 un servicio web, ofrecían JSON y XML. Algo así como el 90% de los implementadores eligieron JSON.
Teniendo en cuenta su caso específico en el que ya está haciendo JavaScript en el lado del cliente, iría con JSON por estos motivos:
Como JSON es nativo de javascript, tendría que escribir menos código en el lado del cliente: solo eval()(o, mejor aún JSON.parse()) , la cadena JSON y obtener un objeto que pueda usar.
Al mismo tiempo, evaluar 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 reducirá la cantidad de datos que se ejecutan a través del cable y mejorará el rendimiento a ese respecto.
Aquí hay algunas lecturas adicionales: http://www.subbu.org/blog/2006/08/json-vs-xml
eval()ing JSON un gran no-no?
Algunas otras cosas con las que me he encontrado en el XML vs JSON relm:
JSON es muy bueno para
Lo que significa que tiende a gustarle una matriz o una matriz anidada. Sin embargo, a JSON le faltan ambos
Entonces, si combinara dos o más servicios JSON, podría haber posibles conflictos de espacio 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.
Por lo general, JSON es más compacto y más rápido de analizar.
Prefiere XML si:
Un caso importante de (casi) XML: intentar detectar cuándo enviar fragmentos de HTML es más beneficioso que enviar datos sin procesar. AHAH puede hacer maravillas en aplicaciones simples, pero a menudo se pasa por alto. Por lo general, este estilo supone que un servidor envía fragmentos HTML que se incluirán en la página web sin procesamiento.
Por lo general, en los casos de AHAH, CSS se aprovecha al máximo para masajear fragmentos visualmente e implementar condicionales simples como ocultar / mostrar partes relevantes del fragmento utilizando configuraciones específicas del usuario o 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 de analizar y transferir (en la mayoría de los casos).
Como está utilizando 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 atravesarlo manualmente (no sé cómo funciona esto en Javascript, pero es difícil / más molesto en la mayoría de los idiomas con los que he usado bibliotecas XML).
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 ligero.
El análisis XML siempre consume muchos recursos del navegador y debe evitarse tanto como podamos a menos que se requiera lo contrario.
Tengo una publicación de blog sobre el tema que detalla la historia de los protocolos web (es decir, SOAP, XML, JSON, REST, POX, etc.) que proporciona un resumen, así como algunas ventajas y desventajas de cada uno: http://www.servicestack.net / mythz_blog /? p = 154
De hecho, creo que puedes dibujar 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 estricto 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, por ejemplo, fechas, horas, enumeraciones, tipos definidos por el usuario e incluso herencia de tipos, etc. SOAP se construye efectivamente sobre el conjunto de características XML que proporciona una forma estandarizada de describir sus servicios web ( ej. 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 de desarrollar, pero al mismo tiempo hay muchas más herramientas disponibles para usted y la mayoría de los lenguajes modernos proporcionan herramientas automatizadas para generar los poderes de sus clientes, lo que supone una carga apagado cuando intenta interoperar con servicios externos.
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 si necesita acceder a su servicio web desde muchos idiomas diferentes.
Para todos sus beneficios, XML también tiene inconvenientes. 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 desea recuperar / recorrer. También extrapola la carga útil haciéndola más detallada de lo que debe ser. Tener la opción de generar atributos y elementos significa que sus clases no se asignan bien a un documento XML. Estas características por sí solas hacen que sea un ajuste programático deficiente para la mayoría de los idiomas, lo que hace que sea más tedioso y engorroso trabajar con él.
JSON, por otro lado, es todo lo contrario a XML en muchos sentidos, ya que está tipeado de manera muy flexible y solo tiene soporte simple para tipos básicos: Número, Bool, cadena, Objetos y Matrices. Todo lo demás esencialmente tiene que encajar en una cadena. Esto no es excelente cuando se trata de comunicarse a través de los límites del idioma, ya que deberá cumplir con algunas especificaciones no estándar fuera de banda si desea admitir tipos más específicos. Por el lado positivo, su conjunto de características limitadas hace un buen ajuste programático a la mayoría de los lenguajes, y es perfectamente adecuado para JavaScript, ya que una cadena JSON se puede evaluar directamente en un objeto JavaScript.
Tamaño y rendimiento
Tengo algunos puntos de referencia de la base de datos Northwind disponibles que comparan el tamaño y la velocidad entre las implementaciones de Microsofts XML y JSON. Básicamente, XML es más del doble del tamaño de JSON, pero al mismo tiempo parece que Microsoft hizo un gran esfuerzo para optimizar su XML DataContractSerializer, ya que es más de un 30% más rápido que su JSON. Parece que tiene que hacer una compensación entre tamaño y rendimiento. No contento con este hecho, decidí escribir mi propio JsonSerializer rápido, que ahora es 2.6 veces más rápido que el XML de MS, lo mejor de ambos mundos :).
Cuando sigue la ruta JSON, se encuentra con los mismos problemas que XML enfrentó hace 10 años:
Mezclar datos de dos fuentes diferentes en un paquete JSON puede hacer que las etiquetas de los elementos se encuentren entre sí. Mezcle un albarán y una factura, y de repente la dirección De podría significar algo muy diferente. Es por eso que XML tiene espacios de nombres .
La conversión entre diferentes estructuras JSON requeriría escribir código mundano. Una forma más declarativa de asignar datos facilitaría el trabajo. Es por eso que XML tiene XSLT .
Describir la estructura de un paquete JSON (sus campos, tipos de datos, etc.) es necesario para que las personas se conecten a sus servicios. Es esencial tener un lenguaje de metadatos para esto. Es por eso que XML tiene esquemas .
Llevar a cabo dos conversaciones simultáneas cliente-servidor tiene mucho cuidado. Si le hace dos preguntas al servidor y obtiene una respuesta, ¿cómo sabe qué pregunta responde? Es por eso que XML tiene WS-Correlation .
Desde la primera línea en http://json.org/xml.html
El Lenguaje de marcado extensible (XML) es un formato de texto derivado del Lenguaje de marcado generalizado estándar (SGML). En comparación 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 una pulgada de grosor. Esto se debe a que el formato y la estructuración de los documentos es un negocio complicado. . . .
Claramente, JSON es más rápido, pero es aún 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.
Utilizo JSON para cualquier tipo de configuración, intercambio de datos o mensajería. Solo uso XML si tengo que hacerlo por otros motivos o para marcar semánticamente datos similares a documentos.
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 imprescindible para aprovechar el poder de la plantilla del lado del cliente.
Según 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
Usando XML
Encontré este artículo en el bazar digital realmente interesante.
Algunas partes del artículo se citan a continuación.
Sobre los profesionales de JSON:
Si todo lo que desea transmitir son valores atómicos o listas o valores hash de valores atómicos, JSON tiene muchas de las ventajas de XML: es directamente utilizable en 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 claro, su diseño es formal y conciso, los documentos JSON son fáciles de crear y utiliza Unicode. ...
Acerca de los profesionales XML:
XML trata notablemente bien con la riqueza completa de 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 resistir meter un "¡Te lo dije!" ficha en mi escritorio. Espero ver qué hacen los amigos de JSON cuando se les pide que desarrollen API más completas. Cuando quieran intercambiar datos menos estructurados, ¿lo incluirán en JSON? Veo menciones ocasionales de un lenguaje de esquema para JSON, ¿seguirán otros idiomas? ...
Reglas rápidas:
Explicación:
El único papel de JSON es serializar datos orientados a objetos utilizando 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 ni mejorar. 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 considere los dos casos de uso más comunes: comunicación asíncrona cliente-servidor (AJAX) : JSON ha reemplazado casi por completo a XML (The X realmente debería ser una J) y servicios web : JSON ha hecho de XML una alternativa redundante.
La otra cosa para la que XML fue ampliamente utilizado fue para archivos de datos de escritura / lectura humana (?) Para programas, pero aquí también tiene un formato más conciso, más amigable con los programas y más amigable con los humanos en YAML, un superconjunto JSON.
Entonces, 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 fue diseñada .
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 sencilla.
Además, JSON IMHO es mucho más claro que XML, lo que lo convierte en una clara ventaja. Y si está trabajando con .NET, Json.NET es un claro ganador para ayudarlo a trabajar con JSON.