Artículo escrito en septiembre de 2017
JSON se ha apoderado del mundo. Si hoy dos aplicaciones se comunican entre sí a través de Internet, lo más probable es que lo hagan utilizando JSON. El estándar es aceptado por todos los principales actores: de las diez API web más populares, desarrolladas principalmente por grandes empresas como Google, Facebook y Twitter,
solo una API transfiere datos en XML, no JSON. Por ejemplo, Twitter admitió XML hasta 2013, cuando lanzó una nueva versión de la API exclusivamente en JSON. Entre otros desarrolladores, JSON también es popular: según Stack Overflow, se hacen
más preguntas sobre JSON que sobre cualquier otro formato de intercambio de datos .
XML todavía está vivo y se usa mucho. Por ejemplo, en formatos web SVG, RSS y Atom. Si el autor de la aplicación de Android quiere declarar que necesita permiso del usuario, lo hace en el manifiesto de la aplicación escrito en XML. Y XML no es la única alternativa de JSON: algunos desarrolladores optan por YAML o Protocol Buffers de Google. Pero estos formatos están lejos de ser tan populares como JSON, que ahora se ha convertido casi en el estándar de facto para el intercambio de datos entre programas a través de Internet.
El dominio de JSON es sorprendente, ya que en 2005 todos discutían el potencial de "JavaScript y XML asincrónicos" en lugar de "JavaScript y JSON asincrónicos". Por supuesto, existe la posibilidad de que esto no diga nada sobre la relativa popularidad de los dos formatos, solo AJAX parecía ser una abreviatura más atractiva que AJAJ. Pero aunque en 2005 algunas personas ya usaban JSON en lugar de XML (pocas en realidad), todavía se pregunta cómo XML podría caer tan bruscamente que una década después, la frase "JavaScript y XML asíncrono" causa una sonrisa irónica. ¿Qué pasó durante esta década? ¿Cómo ha reemplazado JSON XML en muchas aplicaciones? ¿Y quién inventó este formato de datos, de qué ingenieros y sistemas de todo el mundo ahora dependen?
El nacimiento de JSON.
El primer mensaje JSON se envió en abril de 2001 desde una computadora en un garaje cerca de San Francisco. La historia ha conservado los nombres de los involucrados en el evento: Douglas Crockford y Chip Morningstar, cofundadores de la empresa de consultoría tecnológica State Software.
Estos dos habían estado desarrollando aplicaciones AJAX mucho antes de que apareciera el término AJAX. Pero el soporte de aplicaciones en los navegadores no fue muy bueno. Querían transferir datos a su aplicación después de la carga inicial de la página, pero no encontraron una manera que funcionara en todos los navegadores.
Hoy es difícil de creer, pero Internet Explorer fue el navegador más avanzado en 2001. Desde 1999, Internet Explorer 5 ha admitido la forma inicial de XMLHttpRequest a través de ActiveX. Crockford y Morningstar podrían usar esta tecnología para recuperar datos en la aplicación, pero no funcionó en Netscape 4. Por lo tanto, tuve que buscar un formato diferente que funcionara en ambos navegadores.
El primer mensaje JSON se veía así:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html>
Solo una pequeña parte del mensaje se parece a JSON tal como lo conocemos hoy. El mensaje en sí es en realidad un documento HTML con un par de líneas de JavaScript. La parte similar a JSON es solo un literal de JavaScript para la función
receive() .
Crockford y Morningstar decidieron abusar del marco HTML para enviar datos. Para un marco, puede especificar una URL que devuelva un documento HTML similar al anterior. Cuando se recibe el HTML, se inicia JavaScript y devuelve el literal a la aplicación. Esto funcionó con la condición de que la protección del navegador se eludiera cuidadosamente para evitar que el niño acceda a la ventana principal: como puede ver, Crockford y Morningstar establecieron explícitamente el dominio del documento. Esta técnica a veces se denomina marco oculto; a
menudo se usaba a fines de los 90 antes de la XMLHttpRequest normal .
Lo sorprendente de la primera publicación de JSON es que no es nada obvio que este sea el primer uso de un nuevo tipo de formato de datos. ¡Es solo JavaScript! De hecho, la idea de usar JavaScript de tal manera es tan simple que Crockford mismo cree que él no fue el primero en hacerlo; afirma que alguien en Netscape usó literales de matriz de JavaScript para transmitir información
en 1996 . Publicar en JavaScript simple no requiere ningún análisis especial. Todo lo hace el intérprete de JavaScript.
De hecho, el primer mensaje JSON en la historia tuvo problemas con el intérprete. JavaScript reserva una gran cantidad de palabras (64 palabras están reservadas en ECMAScript 6) y Crockford y Morningstar las usaron involuntariamente en su mensaje: a saber, la palabra reservada se usa como clave. Como JavaScript tiene tantas palabras reservadas, Crockford decidió no evitarlas, sino simplemente citar todas las claves JSON. El intérprete de JavaScript considera la clave entrecomillada como una cadena, por lo que puede usar con seguridad las palabras reservadas. Es por eso que las claves JSON todavía se citan.
Crockford y Morningstar se dieron cuenta de que el nuevo método se puede utilizar en todo tipo de aplicaciones. Querían llamar al formato JSML (JavaScript Markup Language), pero resultó que la abreviatura ya estaba ocupada con algo llamado Java Speech Markup Language. Por lo tanto, elegimos la notación de objetos Javascript, es decir, JSON. Comenzaron a ofrecer el formato a sus clientes, pero pronto quedó claro que no corrían el riesgo de utilizar una tecnología desconocida sin una especificación oficial. Entonces Crockford decidió escribirlo.
En 2002, Crockford compró el dominio
JSON.org , publicó la sintaxis JSON y una implementación de ejemplo del analizador. El sitio web sigue funcionando, aunque ahora muestra un enlace al estándar JSON ECMA adoptado en 2013. Además de lanzar el sitio, Crockford no hizo prácticamente nada para promover JSON, pero pronto hubo implementaciones del analizador JSON en una variedad de lenguajes de programación. Inicialmente, JSON estaba claramente asociado con JavaScript, pero luego quedó claro que era adecuado para el intercambio de datos entre pares arbitrarios de idiomas.
AJAX incorrecto
JSON recibió un gran impulso en 2005. Luego, un diseñador y desarrollador llamado Jesse James Garrett acuñó el término AJAX en su
artículo . Trató de enfatizar que AJAX no es solo una nueva tecnología, sino "varias a su manera, buenas tecnologías combinadas en nuevas y poderosas formas". Garrett llamó a AJAX un nuevo enfoque para el desarrollo de aplicaciones web. En una publicación de blog, describió cómo los desarrolladores pueden usar JavaScript y XMLHttpRequest para crear aplicaciones más interactivas. Llamó a Gmail y Flickr ejemplos de sitios que dependen de los métodos AJAX.
Por supuesto, "X" en AJAX significaba XML. Pero en preguntas y respuestas posteriores, Garrett llamó a JSON una alternativa perfectamente aceptable. Escribió que "XML es la herramienta de intercambio de datos más funcional para el cliente AJAX, pero se puede lograr el mismo efecto utilizando la notación de objetos Javascript o cualquier formato de estructuración de datos similar".
Los desarrolladores realmente descubrieron que podían usar fácilmente JSON para crear aplicaciones AJAX, y muchos lo eligieron en lugar de XML. Irónicamente, el interés en AJAX ha llevado a una explosión en la popularidad de JSON. Alrededor de este tiempo, JSON llamó la atención de la blogósfera.
En 2006, Dave Weiner, un prolífico bloguero y creador de una serie de tecnologías XML, como RSS y XML-RPC, se
quejó de que JSON estaba reinventando XML sin ninguna buena razón:
“Por supuesto, puedo escribir un procedimiento para analizar [JSON], pero mira hasta dónde llegaron al reinventar la tecnología: por alguna razón, XML no es lo suficientemente bueno para ellos (me pregunto por qué). ¿Quién creó esta parodia? Busquemos un árbol y ahorquemos a un chico. Ahora mismo ".
Es fácil entender la decepción de Weiner. XML nunca ha sido particularmente amado. Incluso el propio Weiner
dijo que no le gustaba el XML . Pero XML fue diseñado como un sistema universal para cualquier aplicación que puedas imaginar. XML es en realidad un metalenguaje que le permite definir idiomas de dominio para aplicaciones individuales, por ejemplo, RSS y SOAP. Weiner cree que es importante crear consenso para todos los beneficios que trae el formato de intercambio común. En su opinión, la flexibilidad de XML es capaz de satisfacer cualquier necesidad. Sin embargo, JSON es un formato que no ofrece ventajas sobre XML, con la excepción de la eliminación de basura, que hizo que XML fuera tan flexible.
Crockford vio la publicación del blog de Weiner y comentó. En respuesta a la acusación de que JSON está reinventando XML, Crockford escribió:
" Reinventar la
rueda es bueno porque puedes darle la vuelta" .
JSON vs XML
Para 2014, JSON fue reconocido oficialmente como un estándar ECMA y RFC. Obtuvo su tipo MIME. JSON ha entrado en las grandes ligas.
¿Por qué JSON se ha vuelto mucho más popular que XML?
En
JSON.org, Crockford enumera algunos de los
beneficios de JSON sobre XML . Él escribe que JSON es más fácil de entender tanto por personas como por máquinas, porque su sintaxis es mínima y su estructura es predecible. Otros bloggers
mencionan la verbosidad XML y el "impuesto de etiqueta". Cada etiqueta de apertura en XML debe tener una etiqueta de cierre, lo que significa una gran cantidad de información redundante. Esto hace que XML sea mucho más grande que el documento JSON equivalente, pero lo más importante es que el documento XML es más difícil de leer.
Crockford
llamó a otra gran ventaja de JSON: que originalmente fue diseñado como un formato para intercambiar información estructurada entre programas. Aunque XML se usó para el mismo propósito, se desarrolló originalmente como un lenguaje de marcado de documentos. Surgió del SGML (Lenguaje de marcado generalizado estándar), que, a su vez, evolucionó del lenguaje de marcado Scribe, destinado a texto de marcado, como LaTeX. En XML, dentro de una etiqueta, puede haber el llamado "contenido mixto", es decir, texto con etiquetas incrustadas que rodean palabras o frases. Se parece a un editor que marca un manuscrito con un marcador rojo o azul, una especie de metáfora del lenguaje de marcado. JSON, por otro lado, no admite un análogo exacto de contenido mixto, lo que significa simplificar la estructura. El documento se representa mejor en forma de árbol, pero al abandonar la idea del documento, Crockford pudo limitar JSON a diccionarios y conjuntos de elementos familiares que todos los programadores usan para crear sus programas.
Finalmente, mi propia suposición es que a la gente no le gustaba la complejidad de XML, y realmente se debía a su diversidad. A primera vista, es difícil distinguir entre el propio XML y sus sublenguajes, como RSS, ATOM, SOAP o SVG. Las primeras líneas de un documento XML típico establecen la versión de XML y luego el sublenguaje específico con el que debe coincidir el documento XML. Estas son muchas opciones en comparación con JSON, que es tan simple que nunca se escribirá una nueva versión de la especificación JSON. Los desarrolladores de XML, en un intento de crear un único formato de intercambio de datos para todo, fueron víctimas de la clásica trampa del programador: complicación técnica excesiva. XML es tan general que es difícil de usar para algo simple.
En 2000, una campaña comenzó a alinear HTML con el estándar XML. Publicó una especificación para HTML compatible con XML, más tarde conocido como XHTML. Algunos fabricantes de navegadores inmediatamente comenzaron a admitir el nuevo estándar, pero rápidamente se hizo evidente que el público en general que trabajaba con HTML no quería cambiar sus hábitos. El nuevo estándar requería una validación XHTML más estricta que la habitual para HTML, pero muchos sitios dependían de reglas HTML gratuitas. Para 2009, los activistas habían dejado de intentar escribir una segunda versión de XHTML cuando quedó claro que el futuro estaba en el estándar HTML5, que no requería el cumplimiento de XML.
Si los esfuerzos de XHTML tuvieron éxito, quizás XML se convertiría en un formato de datos común, como esperaban sus desarrolladores. Imagine un mundo en el que los documentos HTML y las respuestas API tienen exactamente la misma estructura. En un mundo así, JSON podría no haberse vuelto tan popular como lo es hoy. Pero considero que el fracaso de XHTML es una especie de derrota moral para el campo XML. Si XML no ayudaba a HTML, podría haber mejores herramientas para otras aplicaciones. En el mundo real, es fácil entender por qué el formato JSON simple y altamente especializado ha tenido tanto éxito.