Szczegółowe spojrzenie na JSON i XML, część 1: Historia każdego standardu
Opublikowany: 2022-03-11Prawie wszystkie aplikacje komputerowe, z których obecnie korzystamy, od komputerów po aplikacje internetowe i mobilne, opierają się na jednym z dwóch głównych standardów wiadomości: JSON i XML. Obecnie JSON jest najczęściej używanym formatem, ale XML wyprzedził XML dopiero w ciągu ostatnich pięciu lat. Szybkie wyszukiwanie w Internecie hasła „JSON vs. XML” przyniesie niezliczone artykuły i posty na blogu porównujące te dwa standardy i sprowadzające się do stopniowo rosnącej tendencji chwalącej prostotę JSON i krytykującej gadatliwość XML. W wielu artykułach podkreśla się, że JSON jest lepszy od XML ze względu na zwięzłą semantykę i dyskontowanie XML jako nieefektywnego i mylącego standardu z przeszłości. Na pierwszy rzut oka JSON wydaje się być najbardziej popularny – więc czy JSON jest po prostu lepszy od XML? Bitwa „JSON vs. XML” może przejść do JSON na powierzchni, ale w głębi jest więcej niż na pierwszy rzut oka.
W części 1 tego artykułu:
- Przyjrzyj się bliżej historii sieci, aby odkryć pierwotne przeznaczenie XML i JSON.
- Rozważ ewolucję trendów w oprogramowaniu w ostatnich latach, aby ustalić, dlaczego JSON stał się bardziej popularny niż XML.
Historia JSON i XML
Aby odkryć przyczynę popularności JSON nad XML, przyjrzyjmy się historii sieci i jak jej ewolucja od Web 1.0 do Web 2.0 wpłynęła na trendy w rozwoju.
Sieć 1.0: HTML
Początek lat 90. był początkiem Web 1.0. HTML został wprowadzony w 1991 roku i został powszechnie przyjęty przez uniwersytety, firmy i organizacje rządowe jako język sieci. HTML pochodzi z SGML, czyli „standardowego uogólnionego języka znaczników”, wynalezionego w latach 70. przez IBM. Oprócz masowej adopcji HTML uległ masowej adaptacji — wprowadzono rozszerzenia obsługujące multimedia, animacje, aplikacje internetowe, handel elektroniczny i inne. Jako pochodna SGML, HTML nie posiadał ścisłej specyfikacji, która powstrzymywałaby firmy od swobodnego rozszerzania go w celu spełnienia wymagań, które wykraczały poza pierwotną koncepcję. Konkurs na najpopularniejszą przeglądarkę internetową pomiędzy Netscape i Microsoftem przyniósł szybki postęp, ale doprowadził także do nieustannej fragmentacji standardu. Ostra konkurencja spowodowała „katastrofę rozbieżności”, ponieważ rozszerzenie HTML przez obie firmy spowodowało, że przeglądarki wspierały własne, unikalne wersje HTML. Ta katastrofa rozbieżności stała się ogromnym problemem dla aplikacji internetowych, ponieważ programiści zmagali się z pisaniem interoperacyjnego kodu dla przeglądarek.
Sieć 1.1: XML + HTML = XHTML
Pod koniec lat 90. grupa ludzi — w tym Jon Bosak, Tim Bray, James Clark i inni — wymyśliła XML: „eXtensible Markup Language”. Podobnie jak SGML, XML sam w sobie nie jest językiem znaczników, ale specyfikacją definicji języków znaczników. XML był ewolucją od SGML — zaprojektowany, aby zapewnić środki do definiowania i egzekwowania ustrukturyzowanej treści. Uważany za „świętego Graala informatyki” 1 , język XML usiłował „rozwiązać problem uniwersalnej wymiany danych między różnymi systemami” (dr Charles Goldfarb) 2 . Zamiast postępującej fragmentacji HTML, powołano Komitet World Wide Web (W3C) w celu wspierania kompatybilności i porozumienia między branżą w przyjmowaniu nowych standardów dla World Wide Web. 3 W3C przystąpiło do przekształcenia HTML jako aplikacji XML, w wyniku czego powstał XHTML.
XHTML był dużą inicjatywą, która zwróciła uwagę na XML, ale to tylko niewielka część tego, czym jest XML.
XML umożliwił branży określenie, za pomocą ścisłej semantyki, niestandardowych języków znaczników dla dowolnej aplikacji. Ponieważ słowo kluczowe to „ścisła semantyka”, XML zdefiniował standard, który może zapewnić integralność danych w dowolnym dokumencie XML, w dowolnym języku podrzędnym XML. Dla firm programistycznych opracowujących rozproszone aplikacje korporacyjne, które współpracują z różnymi systemami, ważny był język znaczników, który mógłby zapewnić integralność danych. Definiując ustrukturyzowaną zawartość za pomocą XML, firmy wykorzystały cechy tej technologii do współdziałania z dowolną platformą, egzekwowania integralności danych każdej wymiany danych oraz do systematycznego zmniejszania ryzyka związanego z oprogramowaniem w swoich systemach. Dla branży XML zapewnił technologię do przechowywania, komunikowania i weryfikowania wszelkiego rodzaju danych w formie, którą aplikacje na dowolnej platformie mogą łatwo odczytywać i przetwarzać. W przypadku HTML XML obiecał rozwiązać „katastrofę rozbieżności”.
Java i .NET
Na początku XXI wieku sieć była zarządzana przez dwie firmy: Sun i Microsoft. W tamtym czasie krajobraz języków programowania był mocno przechylony po stronie serwera. Wspólna architektura aplikacji internetowych opierała się na serwerach renderujących strony HTML na zapleczu w celu dostarczenia ich do przeglądarki. Podejście to uwypukliło technologie back-endowe, które z kolei spopularyzowały wiodące platformy back-endowe: Java i C#.NET. Opracowana przez Sun Microsystems, Java była liderem nowej generacji języków programowania zorientowanych obiektowo, które rozwiązały problem wielu architektur dzięki nowatorskiemu podejściu „napisz raz uruchomiono w dowolnym miejscu” 4 . Microsoft podążył za .NET, C# i Common Language Runtime (CLR) i skupił się na XML jako podejściu wyboru do rozwiązania zagadki interoperacyjności danych. Microsoft stał się największym orędownikiem XML-a, wybierając go jako integralną część swojej czołowej inicjatywy .NET. Reklamowane jako „platforma usług internetowych XML” aplikacje 5 .NET zostały zaprojektowane tak, aby wykorzystywać XML do komunikacji z innymi platformami. Wybrany jako standard wymiany danych firmy Microsoft, XML został zintegrowany z flagowymi produktami serwerowymi, takimi jak SQL Server i Exchange.
Sieć 1.2: AJAX
Dostarczanie wstępnie renderowanych stron HTML do przeglądarki nie było skalowalne, a sieć potrzebowała alternatywy. Z każdą akcją użytkownika wymagającą załadowania nowej strony z serwera, obciążenie procesu i zużycie przepustowości stały się problemem, ponieważ coraz więcej osób powiększało sieć.
Firmy Netscape i Microsoft próbowały rozwiązać ten problem za pomocą asynchronicznego dostarczania treści: ActiveX i JavaScript. W 1998 roku zespół Microsoft Outlook Web Access opracował koncepcję ActiveX 6 , która została później zaimplementowana przez Mozillę, Safari, Operę i inne przeglądarki w JavaScript jako obiekt XMLHttpRequest
.
AJAX narodził się z Microsoft ActiveX i JavaScript Netscape.
Termin AJAX — skrót od „Asynchroniczny JavaScript i XML” — reprezentuje szeroką gamę technologii internetowych, które można wykorzystać do implementacji aplikacji internetowych, które komunikują się z serwerami w tle bez konieczności ponownego ładowania strony. W artykule, w którym ukuto termin AJAX, 7 8 Jesse James Garrett przedstawił główne pojęcia:
- HTML (lub XHTML) i CSS do prezentacji.
- Model obiektów dokumentu (DOM) do dynamicznego wyświetlania danych i interakcji z nimi.
- XML do wymiany danych i XSLT do manipulacji.
- Obiekt
XMLHttpRequest
do komunikacji asynchronicznej. - JavaScript, aby połączyć te technologie.
Dzięki asynchronicznemu dostarczaniu treści, które zmniejsza obciążenie serwera i pozwala zaoszczędzić znaczną przepustowość, AJAX zmienił zasady gry. Wprowadzenie XMLHttpRequest
do przeglądarek umożliwiło programistom zaimplementowanie bardziej złożonej logiki w interfejsie użytkownika. Google szeroko wdrożył zgodny ze standardami, działający w wielu przeglądarkach AJAX z Gmailem w 2004 r. i Google Maps w 2005 r. 9 W październiku 2004 r. publiczna wersja beta Kayak.com była jednym z pierwszych zastosowań AJAX w handlu elektronicznym na dużą skalę. 10
Web 2.0: aplikacje jednostronicowe
Przyjęcie AJAX jako skalowalnej architektury dla aplikacji internetowych doprowadziło do zarania Web 2.0: aplikacji jednostronicowej (SPA). 11 Zamiast ponownego ładowania całej strony dla każdej interakcji użytkownika, SPA dynamicznie przepisują bieżącą stronę w przeglądarce. Oprócz znacznego zmniejszenia obciążenia serwera i zużycia przepustowości, podejście SPA pozwoliło aplikacjom internetowym przypominać aplikacje desktopowe ze względu na płynną i nieprzerwaną interakcję z użytkownikiem.
W kwietniu 2002 roku Stuart Morris napisał jeden z pierwszych SPA na slashdotslash.com 12 , a później w tym samym roku Lucas Birdeau, Kevin Hakman, Michael Peachey i Evan Yeh opisali jednostronicową implementację aplikacji w amerykańskim patencie 8136109. 13 Patent opisał przeglądarki internetowe wykorzystujące JavaScript do wyświetlania interfejsu użytkownika, uruchamiania logiki aplikacji i komunikowania się z serwerem sieciowym.
Gmail, Mapy Google i publiczna wersja beta Kayak zapoczątkowały nową erę tworzenia aplikacji internetowych. Przeglądarki obsługujące technologię AJAX umożliwiły programistom pisanie rozbudowanych aplikacji internetowych. Prosta semantyka JavaScriptu umożliwiła tworzenie aplikacji dla programistów dowolnego kalibru. Bariera wejścia do rozwoju oprogramowania została znacznie zmniejszona, a poszczególni programiści na całym świecie zaczęli tworzyć własne biblioteki i frameworki. Popularne biblioteki, takie jak jQuery, które normalizują zachowanie AJAX w przeglądarkach różnych producentów, przyczyniły się do dalszego postępu rewolucji AJAX.
Powstanie JSON
W kwietniu 2001 roku Douglas Crockford i Chip Morningstar wysłali pierwszą wiadomość JSON z komputera w garażu Morningstar's Bay Area. Crockford i Morningstar próbowali budować aplikacje AJAX na długo przed wymyśleniem terminu „AJAX”, ale obsługa przeglądarek nie była dobra. Chcieli przekazać dane do swojej aplikacji po załadowaniu strony, ale nie znaleźli sposobu, aby to działało we wszystkich przeglądarkach.
W 2001 roku prace nad AJAX dopiero się rozpoczynały i nie istniała jeszcze interoperacyjna forma obiektu XMLHttpRequest
w Internet Explorerze 5 i Netscape 4. Tak więc Crockford i Morningstar zastosowali inne podejście, które działało w obu przeglądarkach.
Pierwsza wiadomość JSON wyglądała tak:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session," do: "test," text: "Hello world" } ) </script></head></html>
Ta wiadomość jest w rzeczywistości dokumentem HTML zawierającym trochę kodu JavaScript i tylko niewielka część wiadomości przypomina format JSON, jaki znamy dzisiaj. Crockford i Morningstar byli w stanie załadować dane asynchronicznie, wskazując <iframe>
na adres URL, który zwróciłby dokument HTML taki jak ten powyżej. Po otrzymaniu odpowiedzi skrypt JavaScript w HTML zostałby uruchomiony, a poprzez ominięcie zabezpieczeń przeglądarki uniemożliwiających dostęp podokien do rodzica, literał obiektu został przekazany z powrotem do głównej ramki aplikacji. Ta technika oparta na ramkach, czasami nazywana „techniką ukrytej ramki”, była powszechnie stosowana w późnych latach 90. przed rozpowszechnieniem XMLHttpRequest
. 14

To podejście spodobało się programistom, ponieważ zapewniało interoperacyjność we wszystkich przeglądarkach. Ponieważ wiadomość jest po prostu JavaScriptem, nie wymaga żadnego specjalnego parsowania. Pomysł wykorzystania JavaScript w ten sposób był tak prosty, że sam Crockford powiedział, że nie był pierwszą osobą, która to zrobiła — twierdzi, że ktoś w Netscape używał JavaScript do przekazywania informacji już w 1996 roku15 .
Crockford i Morningstar zdali sobie sprawę, że mają coś, co można wykorzystać w różnych zastosowaniach. Nazwali swój format JSON, co jest skrótem od „JavaScript Object Notation”. Zaczęli oferować go klientom, ale wkrótce okazało się, że wielu nie chce zaryzykować nowatorskiej technologii, która nie ma oficjalnej specyfikacji. Więc Crockford zdecydował, że napisze jeden. W 2002 roku Crockford kupił domenę JSON.org i umieścił gramatykę JSON oraz referencyjną implementację parsera. Witryna nadal działa, chociaż zawiera teraz widoczny link do standardu JSON ECMA ratyfikowanego w 2013 r. 16 Po uruchomieniu witryny Crockford niewiele zrobił, aby promować JSON, ale wkrótce znalazł ludzi przesyłających implementacje parsera JSON dla różnych języków programowania. Pochodzenie JSON jest wyraźnie związane z JavaScriptem, ale okazało się, że JSON dobrze nadaje się do wymiany danych między dowolnymi językami.
JSON w AJAX
W 2005 r. Jesse James Garrett ukuł termin „AJAX” w poście na blogu, w którym podkreślił, że AJAX to nie jedna nowa technologia, ale raczej „kilka technologii, z których każda rozwija się na własną rękę, łącząc się na nowe, potężne sposoby”. 16 W swoim poście na blogu opisał, w jaki sposób programiści mogli wykorzystać JavaScript i XMLHttpRequest
do tworzenia nowych rodzajów aplikacji, które byłyby bardziej responsywne i bardziej stanowe niż typowa strona internetowa. Jako przykłady stron internetowych wykorzystujących techniki AJAX wskazał Gmail, Google Maps i Flickr. Chociaż „X” w „AJAX” oznaczał XML, Garrett wskazał na JSON jako całkowicie akceptowalną alternatywę. Napisał, że „XML jest najbardziej rozwiniętym sposobem pobierania danych do i z klienta AJAX, ale nie ma powodu, dla którego nie można osiągnąć tych samych efektów przy użyciu technologii takiej jak JavaScript Object Notation lub innych podobnych środków strukturyzowania danych”. 17
JavaScript i JSON były jednoznacznie przeznaczone do bycia razem. Semantyka JSON jest bezpośrednio odwzorowywana na JavaScript, dzięki czemu jest to natywny format wymiany danych dla języka. Deweloperzy szybko odkryli, że JSON jest łatwiejszy w obsłudze w JavaScript, a wielu wolało go od XML.
Gdy JSON zwrócił uwagę blogosfery, zaczęło się rozprzestrzenianie JSON.
Dlaczego JSON stał się bardziej popularny niż XML?
JSON to natywny format danych w aplikacjach JavaScript. Wraz z popularyzacją JavaScript w ostatniej dekadzie powstało więcej komunikatów JSON niż jakikolwiek inny format danych. Pisanie aplikacji w JavaScript niemal wymusza używanie JSON do wymiany danych. Możliwe są inne formaty, ale wymagają one więcej wysiłku niż w przypadku JSON. Wraz z rosnącą popularnością języka JavaScript w tworzeniu aplikacji, JSON podążał w jego ślady jako łatwy w użyciu i natywnie zintegrowany format wymiany danych.
Jeśli chodzi o blogosferę, o JavaScript (a co za tym idzie JSON) napisano więcej artykułów, próbek i samouczków niż na jakiejkolwiek innej platformie programistycznej.
Historia i droga ewolucyjna sieci odegrały znaczącą rolę w popularyzacji JSON. Według Stack Overflow więcej pytań jest teraz zadawanych na temat JSON niż na temat innych formatów wymiany danych. 18
Według Google Trends podobny profil można zobaczyć porównując zainteresowanie wyszukiwaniem dla JSON i XML. 19
Czy rozprzestrzenianie się JavaScript oznacza, że JSON jest lepszy niż XML?
Społeczności programistów upierają się, że JSON stał się bardziej popularny niż XML ze względu na jego zwięzły zakres deklaratywny i prostą semantykę. Sam Douglas Crockford podsumowuje niektóre zalety JSON na JSON.org: „JSON jest łatwiejszy do zrozumienia zarówno dla ludzi, jak i maszyn, ponieważ jego składnia jest minimalna, a struktura przewidywalna”. 20 Inni krytycy XML skupili się na gadatliwości XML jako „podatku nawiasów kątowych”. 21 Format XML wymaga, aby każdy znacznik otwierający był dopasowany do znacznika zamykającego, co skutkuje nadmiarowymi informacjami, które po zdekompresowaniu mogą sprawić, że dokument XML będzie znacznie większy niż równoważny dokument JSON. I, co być może ważniejsze, programiści mówią: „sprawia to również, że dokument XML jest trudniejszy do odczytania”. 22
JSON był chętnie chwalony ze względu na swoją prostotę i zwięzłą semantykę, a XML oznaczony jako przestarzały standard przeszłości ze względu na jego szczegółowość i pozornie nadmierną złożoność. Wiele artykułów i postów na blogu oferuje ograniczoną perspektywę przy porównywaniu JSON z XML, co prowadzi czytelników do przekonania, że JSON jest zamiennikiem XML. Nie o to chodzi!
Ograniczona perspektywa oferowana przez artykuły i posty na blogach skłoniła czytelników do dyskontowania XML jako przestarzałego, pozostawiając wielu nieświadomych potężnych funkcji, które mogą pomóc im ulepszyć architekturę oprogramowania i odporność na zmiany, a także systematycznie zmniejszać ryzyko związane z oprogramowaniem.
JSON jest bardziej popularny niż XML ze względu na dominację JavaScript jako najczęściej używanego języka w dzisiejszych czasach. Dzięki wpływowi JavaScript na trendy w oprogramowaniu w ostatniej dekadzie, JSON nadal cieszy się coraz większą uwagą niż jakikolwiek inny format wymiany danych. Blogosfera szybko powtarza, że „JSON jest lepszy niż XML”, ale najczęściej te stwierdzenia są nieuzasadnione lub są poparte uproszczonymi porównaniami dotyczącymi semantyki i gadatliwości. Czy więc któryś standard jest lepszy od drugiego? Odpowiedź na to pytanie może dać tylko głębsza ocena każdego standardu.
Wniosek
Od 1990 roku do dziś sieć przeszła długą drogę. Wojny przeglądarek między Netscape i Microsoft doprowadziły do katastrofy rozbieżności HTML i potrzebne było rozwiązanie, aby uratować sieć. XML został wynaleziony, aby sformalizować XHTML i dostarczył świętego Graala dla komputerów jako całości. Od renderowania pełnych stron HTML przez serwery zaplecza po AJAX i SPA, trendy w architekturze internetowej i tworzeniu przeglądarek skupiły się na JavaScript, kierując programistów na całym świecie w kierunku JSON.
Popularność JSON jest skorelowana z popularnością JavaScript. Dzięki łatwości użycia i krótkiej krzywej uczenia się, JavaScript przyniósł więcej nowych programistów do pisania oprogramowania niż jakikolwiek inny język. Dzięki natywnej integracji JSON z najpopularniejszą platformą programistyczną, nie jest zaskakujące, że w Stack Overflow pojawia się więcej pytań dotyczących JSON niż w przypadku jakiegokolwiek innego formatu wymiany danych.
Wraz z trendami w oprogramowaniu w ostatnich latach, które przyciągnęły do branży więcej programistów JavaScript, JSON zyskał tytuł „najpopularniejszego formatu wymiany danych”.
Pozornie bitwa „JSON vs. XML” toczy się w JSON, ale w głębi jest więcej niż na pierwszy rzut oka.
W części 2 tego artykułu przyjrzymy się bliżej technicznym mocnym i słabym stronom JSON i XML oraz ocenimy przydatność każdego standardu do typowych aplikacji i przedsiębiorstwa. Bliższe spojrzenie na „wymianę danych” ujawni zakres jej wpływu na ryzyko związane z oprogramowaniem w całej aplikacji. Głębsze zrozumienie fundamentalnych różnic między JSON i XML pozwoli programistom lepiej ocenić ryzyko związane z oprogramowaniem każdego standardu w odniesieniu do wymagań ich projektu — aby umożliwić programistom tworzenie oprogramowania, które jest bardziej stabilne i bardziej odporne na błędy i przyszłość niewiadome.
Nawiasem mówiąc, ciekawym dziwactwem specyfikacji JSON jest to, że nie można konwertować obiektów JavaScript z relacjami dwukierunkowymi, gdzie właściwości potomne odwołują się do właściwości nadrzędnych, na JSON. Spowodowałoby to błąd Uncaught TypeError: Converting circular structure to JSON
. Aby dowiedzieć się, jak obejść to ograniczenie, zobacz Obsługa relacji dwukierunkowych w JSON .
Bibliografia
1. Internet: encyklopedia historyczna. Chronologia, tom 3, s. 130 (ABC-CLIO, 2005)
2. Podręcznik metadanych, semantyki i ontologii, s. 109 (Światowy Naukowy, grudzień 2013)
3. WebDiy.org — Konsorcjum World Wide Web (W3C) — Historia
4. „JavaSoft dostarcza Javę 1.0” (Sun Microsystems, styczeń 1996)
5. Przestrzenne umożliwienie dostępu do Internetu nowej generacji (David Engen, styczeń 2002)
6. Historia XMLHTTP (AlexHopmann.com, styczeń 2007)
7. Początek Ajaksu - strona 2 (Wiley Publishing, marzec 2007)
8. Ajax: nowe podejście do aplikacji internetowych (Jesse James Garrett, luty 2005)
9. Krótka historia Ajaksu (Aaron Swartz, grudzień 2005)
10. „Co to jest Kayak.com?” (Corporate Backgrounder, październik 2008)
11. Przeglądanie wewnętrzne: rozszerzenie paradygmatu nawigacji przeglądania (Netscape, maj 2003)
12. „Samodzielna witryna internetowa wykorzystująca DHTML” (SlashDotSlash.com, lipiec 2012)
13. Dostarczenie danych i informacji o formatowaniu w celu umożliwienia manipulacji po stronie klienta (US Patent Bureau, kwiecień 2002)
14. „Co to jest Ajax?” Profesjonalny Ajax, wyd. (Wiley, marzec 2007)
15. Douglas Crockford: Saga JSON (Yahoo!, lipiec 2009)
16. Standard ECMA 404 (ECMA International, grudzień 2017)
17. Ajax: nowe podejście do aplikacji internetowych (Jesse James Garrett, luty 2005)
18. Trendy przepełnienia stosu (przepełnienie stosu, 2009-2019)
19. Trendy Google (Google, 2004-2019)
20. JSON: Beztłuszczowa alternatywa dla XML (Crockford, 2006)
21. XML: Podatek kątowy (Coding Horror, maj 2008)
22. Xml jest do bani (WikiWikiWeb, 2016)