Uno sguardo approfondito a JSON e XML, parte 1: la storia di ogni standard

Dal desktop al Web e ai dispositivi mobili, quasi tutte le applicazioni per computer che utilizziamo oggi si basano su uno dei due principali standard di messaggistica: JSON e XML. Oggi, JSON è il formato più utilizzato, ma ha superato XML solo negli ultimi cinque anni. Una rapida ricerca online di "JSON vs. XML" porterà innumerevoli articoli e post di blog che confrontano i due standard e equivalgono a un pregiudizio in progressiva espansione che loda la semplicità di JSON e critica la verbosità di XML. Numerosi articoli insistono sul fatto che JSON sia superiore a XML a causa della sua semantica concisa e lo scartano come uno standard inefficiente e confuso del passato. A prima vista, JSON sembra essere il più popolare, quindi JSON è semplicemente migliore di XML? La battaglia di "JSON vs. XML" potrebbe essere JSON in superficie, ma in profondità c'è più di quanto sembri.

Nella parte 1 di questo articolo, faremo:

1. Dai un'occhiata più da vicino alla storia del Web per scoprire lo scopo originale di XML e JSON.
2. Considera l'evoluzione delle tendenze del software negli ultimi anni per accertare perché JSON è diventato più popolare di XML.

La storia di JSON e XML

Per scoprire il motivo della popolarità di JSON rispetto a XML, esploriamo la storia del Web e come la sua evoluzione dal Web 1.0 al Web 2.0 abbia influenzato le tendenze di sviluppo.

Il Web 1.0: HTML

I primi anni '90 furono gli albori del Web 1.0. L'HTML è stato introdotto nel 1991 ed è stato ampiamente adottato da università, aziende e organizzazioni governative come linguaggio del web. L'HTML deriva da SGML, o "Standard Generalized Markup Language", inventato negli anni '70 da IBM. Oltre all'adozione di massa, l'HTML ha visto un adattamento di massa: sono state incorporate estensioni per supportare contenuti multimediali, animazioni, applicazioni online, eCommerce e altro ancora. In quanto derivato di SGML, l'HTML mancava di una specifica rigorosa per impedire alle aziende di espanderlo liberamente per soddisfare requisiti che andavano oltre il concetto originale. Il concorso per il browser Web più popolare tra Netscape e Microsoft ha prodotto rapidi progressi, ma ha anche portato a una frammentazione incessante dello standard. La forte concorrenza ha provocato una "catastrofe della divergenza" poiché l'aumento dell'HTML da parte delle due società ha indotto i browser a supportare le proprie versioni uniche di HTML. Questa catastrofe della divergenza è diventata un enorme problema per le applicazioni Web poiché gli sviluppatori hanno lottato per scrivere codice interoperabile per i browser.

Il Web 1.1: XML + HTML = XHTML

Alla fine degli anni '90, un gruppo di persone, tra cui Jon Bosak, Tim Bray, James Clark e altri, ha inventato XML: il "linguaggio di markup eXtensible". Come SGML, XML non è di per sé un linguaggio di markup, ma una specifica per la definizione dei linguaggi di markup. XML era un'evoluzione di SGML, progettato per fornire un mezzo per definire e rafforzare il contenuto strutturato. Considerato come “il Santo Graal dell'informatica”, ¹ il linguaggio XML ha cercato di “risolvere il problema dell'interscambio universale di dati tra sistemi dissimili” (Dott. Charles Goldfarb) ² . Al posto della frammentazione in corso dell'HTML, è stato formato il World Wide Web Committee (W3C) per promuovere la compatibilità e l'accordo tra il settore nell'adozione di nuovi standard per il World Wide Web. ³ Il W3C ha deciso di rimodellare l'HTML come applicazione XML, con il risultato di XHTML.

XHTML è stata una grande iniziativa che ha attirato l'attenzione su XML, ma è solo una piccola parte di ciò che è XML.

XML ha fornito al settore un modo per specificare, con una semantica rigorosa, linguaggi di markup personalizzati per qualsiasi applicazione. Con la parola chiave "semantica rigorosa", XML ha definito uno standard che potrebbe affermare l'integrità dei dati in qualsiasi documento XML, di qualsiasi sottolinguaggio XML. Per le società di software che sviluppano applicazioni aziendali distribuite che si interfacciano con sistemi disparati, un linguaggio di markup in grado di affermare l'integrità dei propri dati era significativo. Definendo contenuti strutturati con XML, le aziende hanno sfruttato le caratteristiche di questa tecnologia per interoperare con qualsiasi piattaforma, rafforzare l'integrità dei dati di ogni scambio di dati e ridurre sistematicamente il rischio software dei propri sistemi. Per il settore, XML ha fornito una tecnologia per archiviare, comunicare e convalidare qualsiasi tipo di dati, in una forma che le applicazioni su qualsiasi piattaforma possono leggere ed elaborare facilmente. Per HTML, XML ha promesso di risolvere la "catastrofe della divergenza".

Java e .NET

All'inizio degli anni 2000, il web era governato da due società: Sun e Microsoft. A quel tempo, il panorama dei linguaggi di programmazione era fortemente inclinato sul lato server. L'architettura comune per le applicazioni Web si basava su server che rendevano le pagine HTML sul back-end da consegnare al browser. Questo approccio ha messo in evidenza le tecnologie back-end, che a loro volta hanno reso popolari le principali piattaforme back-end: Java e C#.NET. Sviluppato da Sun Microsystems, Java ha guidato la nuova generazione di linguaggi di programmazione orientati agli oggetti che hanno risolto il problema dell'architettura incrociata con il suo nuovo approccio "scrivi una volta eseguito ovunque" ⁴ . Microsoft ha seguito .NET, C# e Common Language Runtime (CLR) e ha puntato su XML come approccio di scelta per risolvere il puzzle dell'interoperabilità dei dati. Microsoft è diventata la più grande sostenitrice di XML, con l'azienda che ha scelto XML come parte integrante della sua importante iniziativa .NET. Annunciate come "una piattaforma per servizi Web XML", ⁵ applicazioni .NET sono state progettate per utilizzare XML per la comunicazione con altre piattaforme. Selezionato come standard per lo scambio di dati di Microsoft, XML è stato integrato nei suoi prodotti server di punta, come SQL Server ed Exchange.

Il Web 1.2: AJAX

La consegna di pagine HTML prerenderizzate al browser non era scalabile e il Web aveva bisogno di un'alternativa. Con ogni azione dell'utente che richiedeva il caricamento di una nuova pagina dal server, il carico del processo e il consumo di larghezza di banda sono diventati una preoccupazione poiché sempre più persone hanno ingrossato il Web.

Netscape e Microsoft hanno cercato di affrontare questo problema con la distribuzione asincrona dei contenuti: ActiveX e JavaScript. Nel 1998, il team di Microsoft Outlook Web Access ha sviluppato il concetto alla base di ActiveX ⁶ , che è stato successivamente implementato da Mozilla, Safari, Opera e altri browser in JavaScript come oggetto XMLHttpRequest .

AJAX è nato da ActiveX di Microsoft e JavaScript di Netscape.

Il termine AJAX, abbreviazione di "JavaScript e XML asincroni", è arrivato a rappresentare un'ampia gamma di tecnologie Web che possono essere utilizzate per implementare applicazioni Web che comunicano con i server in background senza richiedere il ricaricamento di una pagina. Nell'articolo che ha coniato il termine AJAX, ^{7 8} Jesse James Garrett ha delineato i concetti principali:

1. HTML (o XHTML) e CSS per la presentazione.
2. Il Document Object Model (DOM) per la visualizzazione dinamica e l'interazione con i dati.
3. XML per lo scambio di dati e XSLT per la sua manipolazione.
4. L'oggetto XMLHttpRequest per la comunicazione asincrona.
5. JavaScript per riunire queste tecnologie.

Con la distribuzione asincrona dei contenuti che ha dimostrato di ridurre il carico del server e di risparmiare una notevole larghezza di banda, AJAX è stato un punto di svolta. L'introduzione di XMLHttpRequest nei browser ha consentito agli sviluppatori di implementare logiche più complesse nel front-end. Google ha implementato un'ampia distribuzione di AJAX cross-browser conforme agli standard con Gmail nel 2004 e Google Maps nel 2005. ⁹ E, nell'ottobre 2004, la versione beta pubblica di Kayak.com è stata tra i primi utilizzi su larga scala di AJAX per l'eCommerce. ¹⁰

Il Web 2.0: applicazioni a pagina singola

L'adozione di AJAX come architettura scalabile per le applicazioni web ha portato all'alba del Web 2.0: la Single-page Application (SPA). ¹¹ Invece di ricaricare l'intera pagina per ogni interazione dell'utente, le SPA riscrivono dinamicamente la pagina corrente all'interno del browser. Oltre a una notevole riduzione del carico del server e del consumo di larghezza di banda, l'approccio SPA ha consentito alle applicazioni Web di assomigliare alle applicazioni desktop grazie all'esperienza fluida e ininterrotta durante l'interazione dell'utente.

Nell'aprile 2002, Stuart Morris ha scritto uno dei primi SPA su slashdotslash.com ¹² , e più tardi lo stesso anno Lucas Birdeau, Kevin Hakman, Michael Peachey ed Evan Yeh hanno descritto l'implementazione di una domanda di una pagina nel brevetto statunitense 8.136.109. ¹³ Il brevetto descriveva i browser Web che utilizzavano JavaScript per visualizzare l'interfaccia utente, eseguire la logica dell'applicazione e comunicare con un server Web.

Gmail di Google, Google Maps e la beta pubblica di Kayak hanno dato il via a una nuova era nello sviluppo di applicazioni web. I browser abilitati con AJAX hanno consentito agli sviluppatori di scrivere applicazioni avanzate per il Web. La semplice semantica di JavaScript ha reso possibile lo sviluppo di applicazioni per programmatori di qualsiasi calibro. La barriera all'ingresso nello sviluppo del software è stata notevolmente ridotta e i singoli sviluppatori di tutto il mondo hanno iniziato a contribuire con librerie e framework propri. Le librerie popolari come jQuery, che normalizzano il comportamento di AJAX tra i browser di diversi produttori, hanno fatto progredire ulteriormente la rivoluzione AJAX.

L'ascesa di JSON

Nell'aprile 2001, Douglas Crockford e Chip Morningstar hanno inviato il primo messaggio JSON da un computer nel garage della Morningstar's Bay Area. Crockford e Morningstar stavano cercando di creare applicazioni AJAX ben prima che fosse coniato il termine "AJAX", ma il supporto del browser per ciò che stavano tentando di ottenere non era buono. Volevano passare i dati alla loro applicazione dopo che la pagina era stata caricata, ma non avevano trovato un modo per consentirne il funzionamento su tutti i browser.

Nel 2001, lo sviluppo di AJAX era appena iniziato e non esisteva ancora una forma interoperabile dell'oggetto XMLHttpRequest in Internet Explorer 5 e Netscape 4. Quindi Crockford e Morningstar hanno utilizzato un approccio diverso che funzionava in entrambi i browser.

Il primo messaggio JSON era simile a questo:

 <html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session," do: "test," text: "Hello world" } ) </script></head></html>

Questo messaggio è in realtà un documento HTML contenente alcuni JavaScript e solo una piccola parte del messaggio assomiglia a JSON come lo conosciamo oggi. Crockford e Morningstar sono stati in grado di caricare i dati in modo asincrono puntando un <iframe> a un URL che avrebbe restituito un documento HTML come quello sopra. Quando veniva ricevuta la risposta, il JavaScript nell'HTML veniva eseguito e, aggirando le protezioni del browser che impedivano alle finestre secondarie di accedere al genitore, il valore letterale dell'oggetto veniva restituito al frame principale dell'applicazione. Questa tecnica basata sui frame, a volte chiamata "tecnica dei frame nascosti", era comunemente utilizzata alla fine degli anni '90 prima dell'implementazione diffusa di XMLHttpRequest . ¹⁴

Questo approccio ha attirato gli sviluppatori perché offriva l'interoperabilità su tutti i browser. Poiché il messaggio è solo JavaScript, non richiede alcun tipo di analisi speciale. L'idea di usare JavaScript in questo modo era così semplice che lo stesso Crockford disse di non essere stato il primo a farlo: afferma che qualcuno in Netscape stava usando JavaScript per comunicare informazioni già nel 1996. ¹⁵

Crockford e Morningstar si sono resi conto di avere qualcosa che poteva essere utilizzato in tutti i tipi di applicazioni. Hanno chiamato il loro formato JSON, che è l'abbreviazione di "JavaScript Object Notation". Hanno iniziato a presentarlo ai clienti, ma presto hanno scoperto che molti non erano disposti a rischiare con una nuova tecnologia che mancava di una specifica ufficiale. Quindi Crockford decise che ne avrebbe scritto uno. Nel 2002, Crockford ha acquistato il dominio JSON.org e ha creato la grammatica JSON e un'implementazione di riferimento di un parser. Il sito Web è ancora attivo, sebbene ora includa un collegamento in primo piano allo standard JSON ECMA ratificato nel 2013. ¹⁶ Dopo aver creato il sito Web, Crockford ha fatto poco di più per promuovere JSON, ma presto ha scoperto che le persone inviavano implementazioni di parser JSON per diversi linguaggi di programmazione. L'origine di JSON è chiaramente legata a JavaScript, ma è diventato evidente che JSON era adatto per lo scambio di dati tra linguaggi arbitrari.

JSON in AJAX

Nel 2005, Jesse James Garrett ha coniato il termine "AJAX" in un post sul blog, in cui ha sottolineato che AJAX non era una nuova tecnologia ma piuttosto "diverse tecnologie, ognuna fiorente a sé stante, che si uniscono in nuovi modi potenti". ¹⁶ Il suo post sul blog continuava descrivendo come gli sviluppatori potevano sfruttare JavaScript e XMLHttpRequest per creare nuovi tipi di applicazioni che fossero più reattive e stateful rispetto alla tipica pagina web. Ha indicato Gmail, Google Maps e Flickr come esempi di siti Web che utilizzano tecniche AJAX. Sebbene "X" in "AJAX" stesse per XML, Garrett ha indicato JSON come un'alternativa del tutto accettabile. Ha scritto che "XML è il mezzo più completo per ottenere dati dentro e fuori un client AJAX, ma non c'è motivo per cui non potresti ottenere gli stessi effetti utilizzando una tecnologia come JavaScript Object Notation o qualsiasi mezzo simile per strutturare i dati". ¹⁷

JavaScript e JSON erano inequivocabilmente pensati per stare insieme. La semantica di JSON esegue il mapping direttamente a JavaScript, rendendolo il formato di scambio di dati nativo per la lingua. Gli sviluppatori hanno scoperto rapidamente che era più facile lavorare con JSON in JavaScript e molti sono arrivati ​​​​a preferirlo a XML.

Quando JSON ha attirato l'attenzione della blogosfera, è iniziata la proliferazione di JSON.

Perché JSON è diventato più popolare di XML

JSON è il formato nativo per i dati nelle applicazioni JavaScript. Con la diffusione di JavaScript nell'ultimo decennio, sono stati creati più messaggi JSON di qualsiasi altro formato di dati. La scrittura di applicazioni in JavaScript richiede quasi l'uso di JSON per lo scambio di dati. Sono possibili altri formati, ma richiedono uno sforzo maggiore rispetto a JSON. Con JavaScript che sta guadagnando popolarità per lo sviluppo di applicazioni, JSON ha seguito da vicino la sua scia come formato di interscambio di dati facile da usare e integrato in modo nativo.

Per quanto riguarda la blogosfera, sono stati scritti più articoli, esempi e tutorial su JavaScript (e quindi JSON) rispetto a qualsiasi altra piattaforma di programmazione.

La storia e il percorso evolutivo del web ha giocato un ruolo significativo nella divulgazione di JSON. Secondo Stack Overflow, ora vengono poste più domande su JSON che su altri formati di interscambio di dati. ¹⁸

Secondo Google Trends, si vede un profilo simile confrontando l'interesse di ricerca per JSON e XML. ¹⁹

La proliferazione di JavaScript significa che JSON è migliore di XML?

Le comunità di sviluppatori insistono sul fatto che JSON sia diventato più popolare di XML a causa del suo ambito dichiarativo conciso e della sua semplice semantica. Lo stesso Douglas Crockford riassume alcuni dei vantaggi di JSON su JSON.org: "JSON è più facile da capire sia per gli esseri umani che per le macchine, poiché la sua sintassi è minima e la sua struttura è prevedibile". ²⁰ Altri critici dell'XML si sono concentrati sulla verbosità di XML come "l'imposta sulla fascia angolare". ²¹ Il formato XML richiede che ogni tag di apertura corrisponda a un tag di chiusura, risultando in informazioni ridondanti che possono rendere un documento XML significativamente più grande di un documento JSON equivalente quando non compresso. E, cosa forse più importante, gli sviluppatori dicono: "rende anche più difficile leggere un documento XML". ²²

JSON è stato prontamente elogiato per la sua semplicità e semantica concisa e XML etichettato come uno standard antiquato del passato a causa della sua verbosità e complessità apparentemente eccessiva. Molti articoli e post di blog offrono una prospettiva limitata quando si confronta JSON con XML, portando i lettori a credere che JSON sia un sostituto di XML. Questo non è il caso!

La prospettiva limitata offerta da articoli e post di blog ha portato i lettori a considerare obsoleto XML, lasciando molti ignari delle potenti funzionalità che potrebbero aiutarli a migliorare l'architettura del software e la resilienza al cambiamento, nonché a ridurre sistematicamente il rischio del software.

JSON è più popolare di XML a causa del predominio di JavaScript come linguaggio più utilizzato di oggi. Con l'influenza di JavaScript sulle tendenze del software nell'ultimo decennio, JSON continua a ricevere sempre più attenzione rispetto a qualsiasi altro formato di scambio di dati. La blogosfera è pronta a ripetere che "JSON è meglio di XML", ma il più delle volte queste affermazioni sono lasciate ingiustificate o sono supportate da confronti semplicistici per quanto riguarda semantica e verbosità. Quindi uno standard è migliore dell'altro? La risposta a questa domanda può venire solo da una valutazione più approfondita di ogni norma.

Conclusione

Dal 1990 ad oggi il web ha fatto molta strada. Le guerre dei browser tra Netscape e Microsoft hanno portato a una catastrofe di divergenza dell'HTML ed era necessaria una soluzione per salvare il Web. XML è stato inventato per formalizzare XHTML e ha fornito una soluzione del Santo Graal per l'informatica nel suo insieme. Dal rendering di pagine HTML complete da server back-end ad AJAX e SPA, le tendenze nell'architettura web e nello sviluppo di browser si sono concentrate su JavaScript, guidando gli sviluppatori di tutto il mondo verso JSON.

La popolarità di JSON è correlata a quella di JavaScript. Con la sua facilità d'uso e la breve curva di apprendimento, JavaScript ha portato più nuovi sviluppatori a scrivere software rispetto a qualsiasi altro linguaggio. Con l'integrazione nativa di JSON con la piattaforma di sviluppo più popolare, non sorprende che vengano poste più domande su JSON su Stack Overflow rispetto a qualsiasi altro formato di interscambio di dati.

Con le tendenze software degli ultimi anni che hanno portato più sviluppatori JavaScript nel settore, JSON ha guadagnato il titolo di "formato di scambio di dati più popolare".

In superficie, la battaglia di "JSON vs. XML" va a JSON, ma in profondità c'è più di quanto sembri.

Nella parte 2 di questo articolo, esamineremo più da vicino i punti di forza e di debolezza tecnici di JSON e XML e valuteremo l'idoneità di ciascuno standard per le applicazioni comuni e l'azienda. Uno sguardo più da vicino allo "scambio di dati" rivelerà l'ampiezza della sua influenza fino al rischio software dell'applicazione nel suo complesso. Una comprensione più approfondita delle differenze fondamentali tra JSON e XML consentirà agli sviluppatori di valutare meglio il rischio software di ogni standard in relazione ai requisiti del loro progetto, per consentire agli sviluppatori di creare software più stabile e più resistente ai bug e al futuro sconosciuti.

A proposito, una stranezza interessante della specifica JSON è che non è possibile convertire oggetti JavaScript con relazioni bidirezionali, in cui le proprietà figlio si riferiscono a proprietà padre, in JSON. Ciò comporterebbe un errore Uncaught TypeError: Converting circular structure to JSON . Per un hack attorno a questa limitazione, vedere il supporto delle relazioni bidirezionali in JSON .

Riferimenti

1. Internet: un'enciclopedia storica. Cronologia, Volume 3, p. 130 (ABC-CLIO, 2005)

2. Manuale di metadati, semantica e ontologie, p. 109 (World Scientific, dicembre 2013)

3. WebDiy.org - World Wide Web Consortium (W3C) - Storia

4. "JavaSoft fornisce Java 1.0" (Sun Microsystems, gennaio 1996)

5. Abilitazione spaziale dell'Internet di nuova generazione (David Engen, gennaio 2002)

6. La storia di XMLHTTP (AlexHopmann.com, gennaio 2007)

7. Inizio Ajax - Pagina 2 (Wiley Publishing, marzo 2007)

8. Ajax: un nuovo approccio alle applicazioni Web (Jesse James Garrett, febbraio 2005)

9. Una breve storia dell'Ajax (Aaron Swartz, dicembre 2005)

10. "Cos'è Kayak.com?" (Sfondo aziendale, ottobre 2008)

11. Navigazione interna: estensione del paradigma della navigazione di navigazione (Netscape, maggio 2003)

12. "Un sito Web autonomo che utilizza DHTML" (SlashDotSlash.com, luglio 2012)

13. Consegna di dati e informazioni di formattazione per consentire la manipolazione lato client (US Patent Bureau, aprile 2002)

14. "Cos'è l'Ajax?" Professionista Ajax, 2a ed. (Wiley, marzo 2007)

15. Douglas Crockford: The JSON Saga (Yahoo!, luglio 2009)

16. Norma ECMA 404 (ECMA International, dicembre 2017)

17. Ajax: un nuovo approccio alle applicazioni Web (Jesse James Garrett, febbraio 2005)

18. Tendenze di overflow dello stack (stack overflow, 2009-2019)

19. Google Trends (Google, 2004-2019)

20. JSON: l'alternativa senza grassi a XML (Crockford, 2006)

21. XML: The Angle Bracket Tax (Coding Horror, maggio 2008)

22. Xml fa schifo (WikiWikiWeb, 2016)