Co to jest JSON i jak go używać?
Opublikowany: 2022-08-14
JSON (JavaScript Object Notation) to ustandaryzowany format reprezentacji danych strukturalnych. Chociaż JSON wyrósł z języka programowania JavaScript, jest obecnie wszechobecną metodą wymiany danych między systemami. Większość współczesnych interfejsów API akceptuje żądania JSON i wydaje odpowiedzi JSON, więc warto mieć dobrą praktyczną znajomość formatu i jego funkcji.
W tym artykule wyjaśnimy, czym jest JSON, w jaki sposób wyraża różne typy danych oraz w jaki sposób można go tworzyć i wykorzystywać w popularnych językach programowania. Omówimy również niektóre ograniczenia JSON i alternatywy, które się pojawiły.
Podstawy JSON
JSON został pierwotnie opracowany przez Douglasa Crockforda jako bezstanowy format do przesyłania danych między przeglądarkami i serwerami. Na początku XXI wieku strony internetowe zaczęły asynchronicznie pobierać dodatkowe dane ze swojego serwera po początkowym załadowaniu strony. Jako format tekstowy wywodzący się z JavaScript, JSON uprościł pobieranie i używanie danych w tych aplikacjach. Specyfikacja została ostatecznie ustandaryzowana jako ECMA-404 w 2013 roku.
JSON jest zawsze przesyłany jako ciąg. Te ciągi można dekodować na szereg podstawowych typów danych, w tym liczby, wartości logiczne, tablice i obiekty. Oznacza to, że hierarchie obiektów i relacje mogą być zachowane podczas transmisji, a następnie ponownie złożone po stronie odbiorczej w sposób odpowiedni dla środowiska programistycznego.
Podstawowy przykład JSON
To jest reprezentacja JSON wpisu na blogu:
{ "id": 1001, "title": "Co to jest JSON?", "autor": { "id": 1, "name": "James Walker" }, "tagi": ["api", "json", "programowanie"], „opublikowane”: fałszywe, "publishedTimestamp": null }
Ten przykład ilustruje wszystkie typy danych JSON. Ilustruje również zwięzłość danych w formacie JSON, jedną z cech, które sprawiają, że są one tak atrakcyjne do użycia w interfejsach API. Ponadto JSON jest stosunkowo łatwy do odczytania w stanie, w jakim jest, w przeciwieństwie do bardziej pełnych formatów, takich jak XML.
Typy danych JSON
Sześć typów danych może być natywnie reprezentowanych w JSON:
- Ciągi — ciągi są pisane między podwójnymi cudzysłowami; znaki mogą być pominięte za pomocą odwrotnych ukośników.
- Liczby — liczby są zapisywane jako cyfry bez cudzysłowów. Możesz dołączyć składnik ułamkowy, aby oznaczyć pływak. Większość implementacji analizowania JSON zakłada liczbę całkowitą, gdy nie ma przecinka dziesiętnego.
- Booleans — obsługiwane są wartości literalne
true
ifalse
. - Null — wartość literału
null
może służyć do oznaczania pustej lub pominiętej wartości. - Tablice — tablica to prosta lista oznaczona nawiasami kwadratowymi. Każdy element na liście jest oddzielony przecinkiem. Tablice mogą zawierać dowolną liczbę elementów i mogą używać wszystkich obsługiwanych typów danych.
- Obiekty — obiekty są tworzone przez nawiasy klamrowe. Są zbiorem par klucz-wartość, w których klucze są ciągami, ujętymi w podwójne cudzysłowy. Każdy klucz ma wartość, która może przyjmować dowolny z dostępnych typów danych. Możesz zagnieżdżać obiekty, aby tworzyć kaskadowe hierarchie. Po każdej wartości musi następować przecinek, oznaczający koniec tej pary klucz-wartość.
Parsery JSON automatycznie konwertują te typy danych na struktury odpowiednie dla ich języka. Nie musisz na przykład ręcznie rzutować id
na liczbę całkowitą. Analiza całego ciągu JSON jest wystarczająca do mapowania wartości z powrotem do ich oryginalnego formatu danych.
Semantyka i walidacja
JSON ma pewne zasady, których należy przestrzegać podczas kodowania danych. Ciągi, które nie są zgodne ze składnią, nie będą analizowane przez konsumentów.
Szczególnie ważne jest, aby zwracać uwagę na znaki cudzysłowu wokół ciągów i kluczy obiektowych. Musisz także upewnić się, że przecinek jest używany po każdym wpisie w obiekcie lub tablicy. JSON nie zezwala jednak na końcowy przecinek po ostatnim wpisie – niezamierzone włączenie go jest częstą przyczyną błędów walidacji. Większość edytorów tekstu podkreśla problemy ze składnią, pomagając odkryć błędy.
Pomimo tych wspólnych punktów podróży, JSON jest jednym z najłatwiejszych formatów danych do ręcznego zapisu. Większość ludzi uważa, że składnia jest szybka i wygodna po zapoznaniu się z nią. Ogólnie JSON jest mniej podatny na błędy niż XML, gdzie niedopasowane tagi otwierające i zamykające, nieprawidłowe deklaracje schematu i problemy z kodowaniem znaków często powodują problemy.
Wyznaczanie zawartości JSON
Rozszerzenie .json
jest zwykle używane, gdy JSON jest zapisywany do pliku. Zawartość JSON ma ustandaryzowany typ MIME application/json
, chociaż text/json
jest czasami używany ze względu na zgodność. W dzisiejszych czasach powinieneś polegać na application/json
dla nagłówków HTTP Accept
i Content-Type
.
Większość interfejsów API, które używają JSON, hermetyzuje wszystko w obiekcie najwyższego poziomu:
{ "błąd": 1000 }
Nie jest to jednak wymagane — typ literału jest prawidłowy jako węzeł najwyższego poziomu w pliku, więc poniższe przykłady również są poprawne w formacie JSON:
1000
PRAWDA
zero
Będą dekodować do swoich skalarów w twoim języku programowania.
Praca z JSON
Większość języków programowania ma wbudowaną obsługę JSON. Oto sposób interakcji z danymi JSON w kilku popularnych środowiskach.
JavaScript
W JavaScript metody JSON.stringify()
i JSON.parse()
służą do kodowania i dekodowania ciągów JSON:
stały post = { id : 1001 , tytuł : „Co to jest JSON?” , autor : { id : 1 , nazwa : "James Walker" } } ; const encodedJson = JSON. skrócić ( post ) ; // {"id": 1001, "title": "Co to jest JSON?", ...} konsola. log ( encodedJson ) ; const dekodowanyJson = JSON. analizować ( encodedJson ) ; // James Walker konsola. log ( decodedJson. autor . nazwa ) ;
PHP
Równoważnymi funkcjami w PHP są json_encode()
i json_decode()
:
$post = [ "id" => 1001 , "title" => "Co to jest JSON?" , "autor" => [ "id" => 1 , "imię" => "James Walker" ] ] ; $encodedJson = json_encode ( $post ) ; // {"id": 1001, "title": "Co to jest JSON?", ...} echo $encodedJson ; $decodedJson = json_decode ( $encodedJson , true ) ; // James Walker echo $decodedJson [ "autor" ] [ "imię" ] ;
Pyton
Python zapewnia json.dumps()
i json.loads()
odpowiednio do serializacji i deserializacji:

importuj json post = { "id" : 1001 , "title" : "Co to jest JSON?" , "autor" : { "id" : 1 , "imię" : "James Walker" } } encodedJson = json. zrzuty ( post ) # {"id": 1001, "title": "Co to jest JSON?", ...} drukuj ( encodedJson ) dekodowanyJson = json. ładuje ( encodedJson ) # James Walker print ( decodedJson [ "autor" ] [ "imię" ] )
Rubin
Ruby oferuje JSON.generate
i JSON.parse
:
wymagać "json" post = { "id" => 1001 , "title" => "Co to jest JSON?" , "autor" => { "id" => 1 , "imię" => "James Walker" } } encodedJson = JSON. generuj ( post ) # {"id": 1001, "title": "Co to jest JSON?", ...} umieszcza zakodowanyJson dekodowanyJson = JSON. analizować ( encodedJson ) # James Walker umieszcza decodedJson [ "autor" ] [ "imię" ]
Ograniczenia JSON
JSON to lekki format, który koncentruje się na przekazywaniu wartości w Twojej strukturze danych. Dzięki temu jest szybki w analizie i łatwy w obsłudze, ale oznacza, że istnieją wady, które mogą powodować frustrację. Oto niektóre z największych problemów.
Bez komentarza
Dane JSON nie mogą zawierać komentarzy. Brak adnotacji zmniejsza przejrzystość i zmusza do umieszczania dokumentacji w innym miejscu. Może to sprawić, że JSON nie będzie odpowiedni w sytuacjach, takich jak pliki konfiguracyjne, w których modyfikacje są rzadkie, a cele pól mogą być niejasne.
Brak schematów
JSON nie pozwala zdefiniować schematu dla Twoich danych. Na przykład nie ma możliwości wymuszenia, że id
jest wymaganym polem całkowitym. Może to prowadzić do niezamierzonych zniekształceń struktur danych.
Brak referencji
Pola nie mogą odwoływać się do innych wartości w strukturze danych. Często powoduje to powtarzanie, które zwiększa rozmiar pliku. Wracając do wcześniejszego przykładu postu na blogu, możesz mieć listę postów na blogu w następujący sposób:
{ "posty": [ { "id": 1001, "title": "Co to jest JSON?", "autor": { "id": 1, "name": "James Walker" } }, { "id": 1002, "title": "Co to jest SaaS?", "autor": { "id": 1, "name": "James Walker" } } ] }
Oba posty mają tego samego autora, ale informacje związane z tym obiektem musiały zostać zduplikowane. W idealnym świecie implementacje parsera JSON byłyby w stanie wytworzyć strukturę pokazaną powyżej z danych wejściowych podobnych do następujących:
{ "posty": [ { "id": 1001, "title": "Co to jest JSON?", "autor": "{{ .autorzy.james }}" }, { "id": 1002, "title": "Co to jest SaaS?", "autor": "{{ .autorzy.james }}" } ], "autorzy": { "James": { "id": 1, "name": "James Walker" } } }
Obecnie nie jest to możliwe w przypadku standardowego JSON.
Brak zaawansowanych typów danych
Sześć obsługiwanych typów danych pomija wiele typowych rodzajów wartości. JSON nie może natywnie przechowywać dat, godzin ani punktów geolokalizacji, więc musisz wybrać własny format tych informacji.
Powoduje to niewygodne rozbieżności i skrajne przypadki. Jeśli Twoja aplikacja obsługuje znaczniki czasu jako ciągi, na przykład 2022-07-01T12:00:00+00:00
, ale zewnętrzny interfejs API przedstawia czas w sekundach po epoce Uniksa – 1657287000
– musisz pamiętać, kiedy używać każdego z formaty.
Alternatywy JSON
YAML jest wiodącą alternatywą JSON. Jest to nadzbiór formatu, który ma bardziej czytelną dla człowieka prezentację, niestandardowe typy danych i obsługę odwołań. Ma na celu rozwiązanie większości problemów związanych z użytecznością związanych z JSON.
YAML zyskał szerokie zastosowanie w plikach konfiguracyjnych oraz w narzędziach DevOps, IaC i obserwowalności. Jest rzadziej używany jako format wymiany danych dla interfejsów API. Względna złożoność YAML oznacza, że jest on mniej przystępny dla nowicjuszy. Małe błędy składniowe mogą powodować mylące błędy analizy.
Bufory protokołów (protobufy) to kolejny nowy rywal JSON przeznaczony do serializacji danych strukturalnych. Protobufy mają deklaracje typu danych, wymagane pola i obsługę większości głównych języków programowania. System zyskuje na popularności jako wydajniejszy sposób przesyłania danych w sieciach.
Streszczenie
JSON to tekstowy format reprezentacji danych, który może kodować sześć różnych typów danych. JSON stał się podstawą ekosystemu tworzenia oprogramowania; jest obsługiwany przez wszystkie główne języki programowania i stał się domyślnym wyborem dla większości interfejsów API REST opracowanych w ciągu ostatnich kilkudziesięciu lat.
Chociaż prostota JSON jest częścią jego popularności, nakłada również ograniczenia na to, co można osiągnąć za pomocą formatu. Brak obsługi schematów, komentarzy, odwołań do obiektów i niestandardowych typów danych oznacza, że niektóre aplikacje uznają, że przerosną możliwości JSON. Młodsze alternatywy, takie jak YAML i Protobuf, pomogły sprostać tym wyzwaniom, podczas gdy XML pozostaje pretendentem do aplikacji, które chcą zdefiniować schemat danych i nie mają nic przeciwko gadatliwości.