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 *