Prawdziwa historia JSONa
HRejterzy w jednym w swoich filmów obarczyli winą, za problem w projekcie, JSONa. Zakładając, że to on jest winny tak wielu błędów w projektach IT - może warto go lepiej poznać. Poznajcie prawdziwą historię JSONa.
From this article you will learn:
Co to jest JSON i jak się poprawnie wymawia tę nazwę
Na czym polega serializacja i marshalling
Jaki związek ma Cartoon Network z powstaniem JSONa
Jakie są zalety i wady formatu JSON
Kto jest najbardziej znanym człowiekiem w branży IT? Wiadomo - JSON (czyt. dżejson). Zastanawialiście się kiedyś skąd się wziął? Czy może to jest ta sama postać co Jason Voorhees? Mogłoby być całkiem nieprzyjemnie gdyby tak było w rzeczywistości.
Na szczęście JSON to nie człowiek. JSON to format danych tekstowych, który służy do przekazywania treści. Głównym założeniem tego formatu było to, że musi on być lekki i niezależny od jakiegokolwiek języka programowania. Już we wstępie dokumentu, który położył podwaliny pod jego powstanie są zapisane te dwa założenia. Ale od początku...
Zanim pojawił się JSON
Informatyka to nauka o informacjach, ich przekazywaniu, pobieraniu, przetwarzaniu oraz przechowywaniu. Zwróćcie uwagę na to, że w tej definicji słowem nie wspomniano o programowaniu. Co więcej - można pokusić się o stwierdzenie, że takiemu opisowi informatyki bliżej do analizy danych aniżeli do programowania.
Biorąc powyższe pod uwagę - informatyka ma rozwiązywać problemy związane z informacjami, a jednym z tych problemów jest ich przesyłanie. Jak zatem przesyłać dane? Musimy się zgodzić, że przesłanie skomplikowanych struktur takich jak obiekty czy tablice byłoby samo w sobie trudne, niewygodne i mało bezpieczne. Ponadto struktura obiektów w różnych językach może być różna, a to może być problematyczne - bo różne języki wcale nie muszą się rozumieć. Wymyślono zatem procesy, które mają to ułatwić.
Serializacja i marshalling
Oba procesy służą do zmiany danych w prostsze struktury, najczęściej strumienie bajtów. W procesie serializacji tylko dane z obiektu są zapisywane do formy wyjściowej. Natomiast marshalling robi coś więcej. Oprócz serializacji danych z obiektu przygotowywana jest informacja o implementacji danego obiektu. Sprowadza się to do tego, że jeśli jakikolwiek program będzie chciał skorzystać z otrzymanych danych, będzie zmuszony do odpowiedniego przygotowania środowiska, poprzez pobranie kodu i jego załadowanie. Serializacja jest częścią marshallingu.
Skoro wiemy już jak możemy uprościć nasze dane, to należałoby wybrać jeszcze format tych danych. Przesyłanie danych binarnych jest oczywiście najlżejsze i tak też pierwotnie to zorganizowano, natomiast jest również najmniej czytelne. Powiedzmy sobie szczerze - kto z nas potrafi szybko analizować kod binarny?
Ponadto różne języki programowania rozwinęły własne formaty serializacji binarnej, co utrudniało odczytywanie danych pomiędzy różnymi językami programowania. Dodatkowo w latach 90. routery blokowały dane, które wyglądały podejrzanie - no cóż, strumienie bajtów do podejrzanych należały, co w ostateczności doprowadziło do sytuacji, że dozwolona była tylko komunikacja tekstowa.
W 1996 roku rozpoczęły się prace nad „nowym” językiem znaczników, który miał służyć do przesyłania zserializowanych danych. Język ten nazwano XML (Extensible Markup Language). Warto tutaj dodać, że tak naprawdę XML nie pojawił się znikąd - bazował on na SGML (Standard Generalized Markup Language), który został wydany jeszcze w latach 80.
Standard XML został opublikowany w 1998 roku przez organizację W3C. Pach… cóż chcieć więcej? XML zaczął obowiązywać i wszystko byłoby dobrze, gdyby nie fakt, że XML jest dość ciężki. Spójrzcie na poniższy przykład z menu:
Sporo się tutaj dzieje, prawda? Zaczęto narzekać na XMLa. Fala krytyki dotyczyła przede wszystkim jego rozciągłości, skomplikowania i nieczytelności.
Douglas Crockford i Cartoon Network
Douglas Crockford to programista, który zaczynał swoją karierę programistyczną od pracy w Atari na początku lat 80. Jest uważany za jednego z guru JSa, chociaż na swojej stronie internetowej stwierdza, że o wiele bardziej pasuje do niego określenie Mahatma JSa. Znany jest jako autor wielu ciekawych publikacji, np. „JavaScript: Good Parts” czy „How JavaScript Works”.
Na początku lat 2000 Douglas Crockford zaproponował nowy format danych oparty o JavaScript (a w zasadzie o standard ECMA-262 3rd Edition z grudnia 1999 roku) i nazwał go JavaScript Object Notation, czyli JSON. Z założenia miał to być lekki, tekstowy i niezależny od jakiegokolwiek języka programowania format. Swój projekt oparł o konwencje znane z rodziny języków C.
Prekursorem nowego formatu była wtyczka do przeglądarek przygotowana na zlecenie Cartoon Network dla przeglądarkowej gry dla dzieci. Wtyczka ta w zasadzie odpowiadała za komunikację tekstową w samej grze. Miała to być lżejsza alternatywa dla Flasha, który w tamtych czasach był bardzo popularny. Niemniej duży wpływ na rozwinięcie tego pomysłu miało pojawienie się w marcu 1999 roku technologii AJAX (do tworzenia asynchronicznych aplikacji webowych).
Tym oto sposobem w kwietniu 2001 roku Douglas Crockford oraz Chip Morningstar wysłali pierwszego JSONa w świat.
Standaryzacja
Jak wspomniałem powyżej Douglas Crockford oparł swój pomysł o najnowszy dostępny standard języka ECMAScript - ECMA 262 (3rd Edition). Swój format opisał w nieformalnym dokumencie RFC 4627. Natomiast w związku ze wzrostem popularności JSONa należało stworzyć jeden standard, który wymusiłby poprawny sposób korzystania z nowego podejścia.
Stało się to w ramach standardu ECMA-404 z 2013 roku, który został zaktualizowany w 2017 roku.
Czy JSON rzeczywiście jest taki lekki?
Główną zaletą JSONa była jego lekkość w porównaniu do ówcześnie panującego w komunikacji XML’a. Porównajmy formę menu restauracyjnego z pierwszego przykładu (XML) z wersją przygotowaną w formacie JSON z tymi samymi danymi:
To, co możemy zauważyć od razu to fakt, że składnia JSONa przypomina obiekty JavaScript’owe. W czasach, gdy powstał JSON było to rzeczywiście coś całkowicie nowego i warto podkreślić, że zapytania zyskały na lekkości. Powyższy przykład jest o około 20% lżejszy niż jego odpowiednik w XML.
Dzisiaj natomiast często mówi się, że JSON jest już za ciężki. Powstają coraz to nowe alternatywy, oparte o serializację binarną, takie jak ION, BSON, Smile, CBOR, MessagePack, Avro czy FlatButters.
Nikt nie jest idealny. JSON też.
Jedną z wad, która jest wskazywana, gdy mówimy o formacie JSON jest fakt, że tak naprawdę mamy do dyspozycji tylko obiekty, tablice i typy prymitywne. Bardziej złożone struktury musimy odpowiednio przygotować (przekształcić, zmapować), aby mogły znaleźć się w formacie JSON.
Ponadto jest cięższy niż formaty binarne, nie można używać komentarzy i nadal jest mniej powszechny od formatów opartych o SGML, takich jak XML.
Podsumowanie
W 2017 roku ustalono, że nazwa JSON będzie wymawiana tak samo jak imię bohatera z mitu „Jason and the Argonauts”. Już kilka lat wcześniej Douglas Crockford stwierdził, że osobiście jest zwolennikiem takiego sposobu wymawiania, ale nie ma to dla niego większego znaczenia.
Tym oto sposobem dobrnęliśmy do końca historii JSONa. Pytanie czy to taki prawdziwy koniec - skoro format ten jest tak szeroko rozpowszechniony. Spotkamy go przecież w zapytaniach RESTowych, jako bazy danych, w plikach konfiguracyjnych różnych aplikacji i w wielu innych miejscach.
Comments (0)
No one has posted anything yet, but that means.... you may be the first.