Czym jest JSON? Kompletny przewodnik dla programistów

Jeśli piszesz kod dłużej niż tydzień, prawie na pewno natknąłeś się na JSON. Pojawia się wszędzie — odpowiedzi REST API, pliki konfiguracyjne, dokumenty bazodanowe, storage przeglądarki, logi. Ale czym właściwie jest i dlaczego stał się formatem, który pożarł cały web?

JSON to skrót od JavaScript Object Notation. Mimo nazwy jest całkowicie niezależny od języka i ma biblioteki w każdym większym języku programowania. Douglas Crockford sformalizował go na początku lat 2000 jako prostszą alternatywę dla XML-a w komunikacji przeglądarka–serwer. Specyfikacja jest też ustandaryzowana jako ECMA-404 i jest tak krótka, że mieści się na wizytówce — i to częściowo dlatego wygrał.

Jak właściwie wygląda JSON?

Oto fragment JSON-a reprezentujący obiekt użytkownika. Ten jeden przykład pokrywa wszystkie sześć typów danych, które wspiera JSON:

{
  "name": "Alice",
  "age": 30,
  "score": 98.5,
  "active": true,
  "nickname": null,
  "tags": ["developer", "blogger"],
  "address": {
    "city": "Berlin",
    "country": "Germany"
  }
}

Sześć typów danych JSON

JSON wspiera dokładnie sześć typów wartości. Tylko tyle. Ta prostota to ficzer — cały format nauczysz się w jedno popołudnie.

{
  "string":  "Hello, world",
  "integer": 42,
  "float":   3.14159,
  "boolean": true,
  "nothing": null,
  "array":   [1, "two", false, null],
  "object":  { "nested": true }
}

• String — Dowolny tekst w cudzysłowach. "hello", "2024-01-01", "" to wszystko poprawne stringi.
• Number — Liczba całkowita lub zmiennoprzecinkowa. Brak rozróżnienia między int a float. Uwaga: NaN i Infinity nie są poprawnymi liczbami JSON.
• Boolean — true lub false, tylko małymi literami.
• Null — Oznacza "brak wartości". Przydatne dla opcjonalnych pól, które nie zostały jeszcze ustawione.
• Array — Uporządkowana lista wartości. Może mieszać typy: [1, "two", true, null] jest w pełni legalne.
• Object — Zbiór par klucz–wartość. Klucze muszą być stringami w cudzysłowach.

Prawdziwa odpowiedź z API

Tak może wyglądać prawdziwa odpowiedź REST API, gdy wywołasz GET /api/users/42. Zauważ, jak zagnieżdża obiekty i tablice, by reprezentować bogatsze dane:

{
  "id": 42,
  "username": "alice_dev",
  "email": "[email protected]",
  "createdAt": "2023-06-15T09:30:00Z",
  "preferences": {
    "theme": "dark",
    "notifications": true,
    "language": "en"
  },
  "roles": ["user", "editor"],
  "lastLogin": "2024-01-10T14:22:00Z",
  "stats": {
    "postsPublished": 27,
    "commentsWritten": 154,
    "likesReceived": 489
  }
}

W JavaScripcie do preferencji motywu alice_dev dostaniesz się przez user.preferences.theme, a pierwszą jej rolę pobierzesz przez user.roles[0]. To naturalne mapowanie na prymitywy języka jest dokładnie powodem, dla którego JSON jest tak bezbolesny w użyciu.

Reguły składni JSON — pułapki, w które wpada każdy

JSON wygląda prosto, ale ma kilka ścisłych reguł. Pomyl się w jednej i cały payload nie sparsuje się. Oto błędy, które widzę najczęściej:

• Klucze muszą być w podwójnych cudzysłowach. {"name": "Alice"} jest poprawne. {name: "Alice"} nie. To wywraca deweloperów z JavaScriptu, gdzie klucze obiektów bez cudzysłowów działają bez problemu.
• Bez końcowego przecinka. {"a": 1, "b": 2,} rzuci błąd parsowania. JavaScript jest tu pobłażliwy; specyfikacja JSON nie.
• Bez komentarzy. Komentarze // ani /* */ w JSON-ie nie istnieją. Jeśli potrzebujesz plików konfiguracyjnych z komentarzami, rozważ YAML lub TOML.
• Bez undefined. JavaScriptowy undefined w JSON-ie nie istnieje. Dla brakujących wartości używaj null.
• Stringi muszą używać podwójnych cudzysłowów. Stringi w pojedynczych cudzysłowach, jak {'key': 'value'}, są niepoprawnym JSON-em.
• Bez zer wiodących. 042 jest niepoprawne. 42 lub 0.42 są w porządku.

Dlaczego JSON wygrał web

Przed JSON-em XML był królem. Typowa odpowiedź XML API była rozwlekła, wymagała porządnego parsera XML i czuło się, jakby się pracowało przeciwko językowi. JSON mógł być sparsowany przez wbudowaną w JavaScript JSON.parse() — bez żadnych bibliotek. Był mniejszy w transmisji, czytelny na pierwszy rzut oka i mapował się bezpośrednio na obiekty oraz tablice, których deweloperzy i tak używali codziennie.

Pod koniec lat 2000 większość publicznych API zaczęła oferować JSON obok XML. Na początku lat 2010 wiele z nich porzuciło wsparcie dla XML-a całkowicie. Dziś domyślne założenie dla każdego REST API to JSON. Nawet GraphQL, który zastąpił REST-a w wielu kontekstach, nadal używa JSON-a jako formatu odpowiedzi.

JSON jest też zdefiniowany przez to, czego nie wspiera

Niektóre ograniczenia JSON-a to celowe decyzje projektowe, które utrzymują go prostym i interoperacyjnym:

• Brak typu date. Daty to po prostu stringi. Konwencją jest format ISO 8601: "2024-01-15T09:30:00Z".
• Brak danych binarnych. Pliki i obrazy są zazwyczaj kodowane w Base64 do stringa.
• Brak wartości funkcyjnych. {"fn": function(){} } jest niepoprawne. JSON to czyste dane, nigdy kod.
• Brak zduplikowanych kluczy. Technicznie dozwolone przez specyfikację, ale zachowanie jest niezdefiniowane. W praktyce parsery biorą ostatnią wartość.

Przydatne narzędzia do pracy z JSON-em

Oto narzędzia, po które będziesz sięgać nieustannie podczas pracy z JSON-em: JSON Formatter do pretty-printowania zminifikowanych odpowiedzi, JSON Validator do znajdowania błędów składni, JSON Minifier do kompresowania JSON-a na produkcję oraz JSON Path do odpytywania głęboko zagnieżdżonych danych bez pisania pętli.

Oficjalna specyfikacja żyje na json.org i naprawdę warto ją przeczytać — zajmuje około 10 minut, a format zrozumiesz w całości. Formalna specyfikacja IETF to RFC 8259, jeśli kiedykolwiek będziesz musiał rozstrzygnąć spór.

Podsumowanie

JSON to lekki, czytelny dla człowieka format danych oparty na sześciu typach wartości: stringach, liczbach, booleanach, null, tablicach i obiektach. Ma ścisłe reguły składniowe, ale żadnych niespodzianek, gdy już je znasz. Powód, dla którego stał się wszechobecny, nie jest taki, że jest najpotężniejszym formatem — jest nim to, że jest najprostszym formatem, który pokrywa 95% realnych potrzeb danych. Jeśli budujesz cokolwiek związanego z webem, rozumienie JSON-a nie jest opcjonalne. Jest fundamentalne.