JSON vs XML

JSON vs XMLEn esta entrada quisiera hacer una comparativa entre JSON vs XML ya que en varias ocasiones me ha tocado discutir cual es mejor que la otra y siempre se vuelve un tema de conversación de horas.

Mi conclusión a este tema es que ambos son buenos y cada uno tiene sus ventajas y desventajas y son usados para diferentes cosas.

XML

Ventajas:

  • Tiene un formato muy estructurado y fácil de comprender.
  • Puede ser validado fácilmente mediante Schemas(XSD)
  • Se pueden definir estructuras complejas y re utilizables.

Desventajas:

  • Es mas complicado de entender
  • El formato es sumamente estricto.
  • Lleva mas tiempo procesarlo
  • Un error con los namespace puede hacer que todo el documento sea invalido

 

JSON

Ventajas: 

  • Formato sumamente simple
  • Velocidad de procesamiento alta
  • Archivos de menor tamaño

Desventajas:

  • Tiene una estructura enredosa y difícil de interpretar a simple vista

NOTA: Gracias a un colaborar denominado Fugaz que me informo que existe una librería llamada mongoose que sirve para validar JSON aun que por lo que investigue es una librería de JavaScript y desconozco si exista una API similar para Java.

Update 2: Mongoose es una librería utilizada para conectar NodeJS y MongoDB, aun que es posible validar de cierta forma los Objetos JS, en realidad no se utiliza para ello, si no que sirve para validar los objetos antes de ser persistidos en MongoDB.

Una vez que hablamos de las diferencias podría comentar que XML es mucho mejor para la comunicación entre servidores y aplicaciones ya que permite mensajes mucho mas completos, tipificados y ademas pueden ser validados con facilidad.

 

Por otro lado, JSON cuenta con un formato mas simple y fácil de procesar, por lo que es ideal para dispositivos de bajo nivel de procesamiento, como los teléfonos móviles, los cuales son beneficiados ya que se requieren de menos consumo de datos para descargarlos y un consumo menor de batería al procesarlos, desde luego que los teléfonos modernos ya son capaces de procesar información mucho mas rápido pero no podemos confiarnos en todo mundo tendrá uno de esos.

 

Tanto JSON como XML son muy ampliamente utilizados en entornos de integración, donde es necesario transmitir datos desde una aplicación a otra, como lo son los Web Services (SOAP) y los servicios REST (JSON), lo que me lleva a recomendarte el articulo SOAP vs REST, donde explico las diferencias de esta dos tecnologías para la construcción de servicios web.

 

Cierro el tema preguntándote. ¿Tu que opinas, cuando usarías XML y cuand JSON, Crees que alguna de las dos tenga mas futuro?

Artículos relacionados

Autenticación con JSON Web Tokens Los JSON Web Tokens (JWT) se ha convertido rápidamente en un estándar en la autenticación de aplicaciones, pues permite de una forma simple y elegante...

Oscar Blancarte

Ideológico, Innovador y emprendedor, Padre, Tecnólogo y Autor, amante de la ciencia y la tecnología en todos sus colores y sabores. Arquitecto de software & Full Stack Developer con experiencia en la industria del desarrollo de software y la consultoría. Amante de la programación y el Ajedrez.

10 comentarios en “JSON vs XML

  1. emm si existen mecanismos para validar los jsons definidndo unos schemas 🙂 como lo hace mongoose 🙂 , busca hermano y encontrarais la respuesta.

  2. Al contrario, JSON es mucho mas simple de interprestar a simple vista, de hecho JSON es 2 cosas: un subset the java script (por lo que es bastante util en servicios REST, los datos json se interpretan como objetos java script al instante en un browser) y ademas tambien es un subset de YAML (formato de serializacion de datos).

    Al igual que XML existe el standard JSON Schema para validar metadatos, pero en la mayoria de los casos es innecesario pues la filosofia JSON es KISS (keep it simple stupid!), y se asume que tanto el cliente conoce de antemo la estructura de JSON que va a consumir.

    1. Definitivamente JSON es perfecto para REST y de echo menciono que es perfecto para comunicación con dispositivos móviles. con respecto a la simplicidad yo si difiero un poco ya que un XML tiene una sintaxis mas clara(Por lo menos para mí).

      Otro punto que ne gustaría rescatar es cuando mencionas que el cliente menciona de antemano la estructura de los datos, ya que eso es cierto en parte ya que cuando consumimos nuestros propios servicios podemos garantizar la estructura y que los datos que tenga son validos. Pero que pasa cuando leemos servicios de un tercero el cual nos promete cierta estructura y valides de la información pero resulta que no es a si. En un entorno de integración SOA confiar en que el proveedor externo nos envía un mensaje valido es un error que frecuentemente lleva a que los procesos marquen algún error.

        1. Hola Laura, me da gusto que tu interés en el tema, te comento de momento no tengo artículos que hablen de Rest, sin embargo, te puedo contar que los servicios Rest son parecidos a los servicios SOA en algunos puntos, lo principal es que los dos utilizan como protocolo de transporte Http o Https. Una de los puntos más característicos por lo general es que los servicios SOA o SOAP viajan en formato XML mientras que los servicios Rest utilizan Json como formato de los mensajes, sin embargo hay algo que debes de tener en cuenta y por lo general mucha gente ignora, y es que los servicios Rest pueden tener cualquier formato de Entrada/Salida, es decir podrían recibir o responder un Json, un XML, un archivo plano o incluso parámetros en la URL, básicamente podría recibir cualquier cosa que pueda ser enviada por los métodos de http como GET, PUSH, DELETE, POST.

          Por otro lado, la forma de implementar un servicio Rest varía según el lenguaje de programación o herramientas del mercado. Cualquier lenguaje de programación moderno tiene APIs que ayudan a su generación, sin embargo, en mi experiencia siempre es mejor utilizar las herramientas que los líderes del marcado que ya están disponibles y que por lo general no es necesario programar una sola línea de código para generar y exponer los servicios. Yo te podría recomendar productos como Oracle SOA Suite 12c o Mule ESB, los cuales, para mí, son los mejores del mercado.

          Espero que esta breve explicación te sea de utilidad y que te sirva para encaminar tu aprendizaje en Rest, de cualquier forma puedes volver para preguntar cualquier duda.

      1. “con respecto a la simplicidad yo si difiero un poco ya que un XML tiene una sintaxis mas clara”

        En realidad es al revés, JSON tiene una mejor estructura (llaves en lugar de etiquetas) para visualizarlo, interpretarlo y procesarlo con respecto a un XML, sobretodo si es un archivo grande y con objetos anidados.

        “En un entorno de integración SOA confiar en que el proveedor externo nos envía un mensaje valido es un error que frecuentemente lleva a que los procesos marquen algún error”

        No necesariamente tiene que ser así porque con REST la aplicación cliente recibe los códigos de estado propios de HTTP y en base a eso reaccionar de una forma u otra, por otro lado dentro del código de la aplicación un objeto JSON es interpretado como tal en JavaScript y por lo tanto basta una simple validación para saber si un objeto o una propiedad esta presente en él.

        Saludos.

        1. Hola David,
          Es claro que tu tienes una opinión diferente a la mía, y eso es bueno, al final, estamos aquí para discutir y aprender entre todos.
          Realmente yo si creo que un XML es semanticamente mucho más estructurado que un JSON, además, los XML soportan atributos, los cuales sirven como metadatos que dan más información sobre el mismo campo. Con respecto a las validaciones, en correcto que no debemos de confiar en que el usuario mandará bien la información, por eso comento que en XML como en JSON hay tecnologías para poder validar las entradas, y también comente que el XML tiene un XSD el cual es mucho más potente para validar que todo el XML este bien formado.

          Con respecto a tu último párrafo, no creo que sea verdad, por que con el puro código solo te da una remota idea de lo que paso, pero no tienes un mensaje legible para el usuario, para que este pueda tomar las acciones pertinentes para resolver el problema. por ejemplo si el servicio te regresa un 400 (Bad request), ¿como sabría que hacer el usuario?

          1. Hola, yo soy nuevo en estos temas pero acabo de terminar de armar un servicio rest

            En cuento a esta linea:
            por ejemplo si el servicio te regresa un 400 (Bad request), ¿como sabría que hacer el usuario?

            Puedo comentar que ambos tienen parte razón y parte no.

            Depende de nosotros crear Apps/WebServices de calidad, de mi parte cuando recibo un petición JSON, valido que tenga los datos que requiere la llamada, si no es así respondo con un mensaje claro y descriptivo, para la corrección del problema en fase de desarrollo y algunos otros en fase de producción.

            Si bien cuando desarrollamos una app para usuario final, debemos considerar hasta los usos más absurdos para ayuda del usuario, cuando se crea un webservice la responsabilidad es doble ya que también debemos considerar omisiones en el desarrollo del app que consumirá el servicio.

          2. Hola Miguel.
            A lo que yo me refiero con esa frase, es un poco a lo que mencionas, y es que un código 400 no es suficiente, si no que además, es necesario mandar un payload con un mensaje descriptivo del error, de esta forma el código de error (400) le sirve al sistema para identificar que la petición retorno con error, pero el payload le sirve al usuario, pues le muestra un error que hace sentido para un humano.

            Espero haber aclaro el comentario.

            saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *