JSON vs YAML: różnice i przypadki użycia

JSON i YAML to dwa najczęściej używane tekstowe formaty serializacji do opisywania danych strukturalnych: konfiguracja aplikacji, payload API, pliki infrastruktury, manifesty Kubernetes, pipeline'y CI/CD. Oba reprezentują te same fundamentalne struktury (obiekty, listy, skalary), ale z różnymi filozofiami: JSON stawia na czytelność maszynową i uniwersalność, YAML stawia na czytelność ludzką i zwięzłość. Ten artykuł porównuje oba formaty punkt po punkcie, aby pomóc Ci wybrać.

Czym jest JSON?

JSON (JavaScript Object Notation) to format serializacji wprowadzony przez Douglasa Crockforda na początku lat 2000, wywodzący się z literałowej składni obiektu JavaScript. Ustandaryzowany przez RFC 8259 i ECMA-404, jest dziś osiowym formatem webu: niemal wszystkie API REST, bazy NoSQL i konfiguracje frontendowe go używają.

JSON opiera się na dwóch strukturach:

  • Uporządkowana kolekcja par klucz-wartość (obiekt, między klamrami)
  • Uporządkowana lista wartości (tablica, między nawiasami kwadratowymi)

Wartości skalarne to string, number, true, false lub null. Ciągi muszą być otoczone podwójnymi cudzysłowami. JSON nie wspiera komentarzy.

Czym jest YAML?

YAML (YAML Ain't Markup Language) to format, który pojawił się w 2001 roku, zaprojektowany od początku tak, aby być czytelny dla człowieka. Aktualna specyfikacja to YAML 1.2.2. Jego wyróżnikiem jest to, że używa wcięć do wyrażenia hierarchii, na wzór Pythona.

YAML jest nadzbiorem JSON od wersji 1.2: każdy poprawny dokument JSON jest poprawnym dokumentem YAML. Ale YAML dodaje wiele: komentarze, ciągi bez cudzysłowów, wieloliniowe, kotwice i aliasy, tagi do jawnego typowania, wiele dokumentów w jednym pliku (---).

Składnia porównana

Oto ta sama struktura wyrażona w obu formatach.

JSON

{
  "name": "cdrn",
  "version": "1.14",
  "tags": ["seo", "tools", "open-source"],
  "author": {
    "name": "Adrien",
    "email": "contact@example.com"
  },
  "active": true,
  "stars": null
}

YAML

# Configuration projet
name: cdrn
version: "1.14"
tags:
  - seo
  - tools
  - open-source
author:
  name: Adrien
  email: contact@example.com
active: true
stars: null

Na tej samej zawartości YAML zajmuje mniej więcej tę samą liczbę linii, ale unika klamer, nawiasów kwadratowych, przecinków końcowych i cudzysłowów na większości ciągów. Komentarze (linie #) są dozwolone.

Wspierane typy

JSON zna 6 typów: object, array, string, number, boolean, null. Brak natywnej daty, brak binarnego, brak jawnego rozróżnienia liczb całkowitych i zmiennoprzecinkowych.

YAML 1.2 zna te same co JSON i dodaje: znaczniki czasu ISO 8601, binaria (kodowane base64 przez tag !!binary), oddzielne integery i floaty, nieskończoność, NaN i typy spersonalizowane poprzez tagi (!!str, !!int, !!float...). YAML 1.1 akceptował yes/no/on/off jako boolean: klasyczna pułapka w starszych parserach.

Wydajność i ekosystem

JSON jest typowo 3 do 10 razy szybszy w parsowaniu niż YAML, a jego parsery są dostępne wszędzie (zintegrowane z runtime'em niemal wszystkich języków). Biblioteki YAML są cięższe, ponieważ obsługują bogatszą gramatykę (anchors, tags, multi-doc).

Po stronie ekosystemu: JSON dominuje w API HTTP, bazach NoSQL (MongoDB, CouchDB), plikach package.json, composer.json, tsconfig.json. YAML narzucił się w konfiguracji aplikacyjnej i infrastructure-as-code: Symfony, Spring Boot, Rails, Docker Compose, Kubernetes, GitHub Actions, GitLab CI, Ansible.

Tabela porównawcza

Kryterium JSON YAML
Czytelność ludzkaDobraDoskonała
Czytelność maszynowaDoskonałaPoprawna
KomentarzeNieTak (#)
Wcięcia znacząceNieTak
Szybkość parsowaniaSzybkaWolniejsza
Bogate typy (data, binarne)NieTak
Anchors / aliasNieTak
Typowy przypadek użyciaAPI, składowanie, wymiana danychKonfiguracja, infra-as-code

Typowe przypadki użycia

Wybierz JSON, gdy

  • Projektujesz API REST lub endpoint webhook
  • Składujesz dane w bazie NoSQL lub cache
  • Wymieniasz dane między frontendem a backendem
  • Wydajność parsowania jest krytyczna (wysoka przepustowość, edge)
  • Chcesz uniwersalnie wspierany format bez zależności

Wybierz YAML, gdy

  • Piszesz konfigurację aplikacyjną edytowaną ręcznie
  • Potrzebujesz komentarzy do dokumentowania opcji
  • Piszesz Kubernetes, Docker Compose, GitHub Actions, Ansible
  • Chcesz wyciągać wspólne bloki za pomocą kotwic i aliasów
  • Czytelność jest ważniejsza niż szybkość przetwarzania

Rekomendacja

Prosta reguła: JSON dla maszyny, YAML dla człowieka. Jeśli Twój plik jest produkowany lub konsumowany przez program, weź JSON. Jeśli jest pisany i czytany ręcznie, weź YAML. Wiele ekosystemów akceptuje oba: Symfony czyta YAML, JSON i XML do swoich konfiguracji, Kubernetes akceptuje oba dla swoich manifestów. W razie wątpliwości postaw na YAML do konfiguracji ludzkiej i JSON do zautomatyzowanych przepływów.

Możesz przetestować konwersję z jednego formatu na drugi za pomocą naszego konwertera JSON / YAML i szybko sformatować dokument za pomocą formatera JSON.

Często zadawane pytania

Czy YAML jest wolniejszy niż JSON?

Tak, z reguły parsowanie dokumentu YAML kosztuje kilka razy więcej CPU niż parsowanie tego samego dokumentu JSON, ponieważ gramatyka YAML jest bogatsza (wcięcia, tagi, anchors). W praktyce różnica jest pomijalna dla plików konfiguracyjnych. Staje się odczuwalna, gdy parsujesz dziesiątki tysięcy dokumentów w pętli.

Czy można automatycznie konwertować YAML na JSON?

Tak: każdy dokument YAML może być przekonwertowany na JSON bez straty, jeśli unikamy typów specyficznych dla YAML (znaczniki czasu, anchors). Odwrotnie jest jeszcze prościej, JSON jest podzbiorem YAML 1.2. Nasz konwerter obsługuje oba kierunki.

Czy JSON akceptuje komentarze?

Nie, standard JSON ich zakazuje. Istnieją dialekty (JSON5, JSONC), ale nie są uniwersalnie wspierane. Jeśli potrzebujesz komentarzy, weź YAML lub TOML.

Dlaczego Kubernetes używa YAML, a nie JSON?

Manifesty Kubernetes są pisane i czytane przez ludzi. YAML oferuje komentarze, mniej zaszumioną składnię oraz możliwość wyciągania wspólnych bloków przez anchors. API Kubernetes akceptuje również JSON, ale idiomatyczne użycie pozostaje YAML.

Czy YAML naprawdę jest nadzbiorem JSON?

Tak, od YAML 1.2: każdy poprawny dokument JSON jest poprawnym dokumentem YAML. Pozwala to osadzać JSON w pliku YAML bez modyfikacji, co jest praktyczne dla generowanych lub kopiowanych-wklejanych bloków.