JSON vs YAML — Forskjellene forklart

Du har sikkert lagt merke til at noen prosjekter bruker .json-filer til konfigurasjon, mens andre bruker .yaml eller .yml. Begge formater representerer strukturerte data. Begge er lesbare for mennesker. Hva er den faktiske forskjellen, og når bør du velge det ene fremfor det andre?

Jeg har brukt begge mye — JSON er min daglige driver for API-er og datautveksling, YAML er mitt go-to for Kubernetes-manifester, GitHub Actions og Docker Compose. De løser lignende problemer, men har svært forskjellig personlighet.

Side om side: samme konfigurasjon i begge formater

Her er et databasekonfigurasjonsobjekt skrevet i JSON:

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp",
    "ssl": true,
    "pool": {
      "min": 2,
      "max": 10
    },
    "replicas": ["replica1.db", "replica2.db"]
  }
}

Og her er den samme konfigurasjonen i YAML:

database:
  host: localhost
  port: 5432
  name: myapp
  ssl: true
  pool:
    min: 2
    max: 10
  replicas:
    - replica1.db
    - replica2.db

YAML er merkbart mindre rotete. Ingen anførselstegn rundt de fleste strenger, ingen krølleparenteser, ingen kommaer. For en konfigurasjonsfil som mennesker redigerer jevnlig, betyr den klarheten mye. Men YAML oppnår dette ved å være betydelig mer kompleks under overflaten.

Hvor YAML skinner

• Konfigurasjonsfiler redigert av mennesker. CI/CD-pipelines (GitHub Actions, GitLab CI), Kubernetes-manifester, Docker Compose, Ansible playbooks — alt YAML. Ingen tilfeldighet — dette er filer mennesker skriver for hånd.
• Kommentarer. YAML støtter kommentarer med #. Det er enormt for konfigurasjonsfiler der du vil forklare hvorfor en innstilling er som den er. JSON støtter ikke kommentarer i det hele tatt.
• Flerlinjestrenger. YAML har block scalars for innhold på flere linjer som leses naturlig. JSON krever \n-escape-sekvenser.
• Mindre visuelt støy. Ikke nødvendig å sitere de fleste strenger, ingen avsluttende parenteser, ingen bekymringer om etterfølgende kommaer.
• Ankre og aliaser. YAML lar deg definere en verdi én gang og referere til den andre steder med &anchor og *alias — praktisk for DRY-konfigurasjonsfiler.

Hvor JSON vinner

• Strenghet. JSON har én gyldig representasjon for en gitt datastruktur. YAML har et dusin måter å skrive det samme på, noe som skaper inkonsistens på tvers av team.
• Ingen innrykksfeller. JSON bruker krølle- og hakeparenteser. YAML bruker innrykk, noe som betyr at et enkelt feilplassert mellomrom stille kan ødelegge hele konfigurasjonen din.
• Parseytelse. JSON-parsere er raske og enkle. YAML-parsere er komplekse — YAML 1.1 har notorisk vanskelige regler for implisitt typetvang.
• Universell biblioteksstøtte. Alle språk har en kamptestet, zero-dependency JSON-parser. YAML-biblioteker varierer i kvalitet og samsvar med spesifikasjonen.
• Verktøy. Lintere, formatere, schemavalidatorer — JSON-verktøy er mer modne og bredt tilgjengelige.
• API-payloads. JSON er det universelle språket for web-API-er. Å sende YAML over HTTP ville vært ukonvensjonelt og skapt friksjon.

YAML-fellene som vil brenne deg

YAML har noen genuint overraskende oppførsler som har forårsaket virkelige produksjonshendelser. De fleste av dem kommer fra de implicitte typereglene i YAML 1.1, som YAML 1.2 strammet inn. Lær disse før du stoler på YAML til noe kritisk:

# YAML 1.1 implicit type coercion — all of these become booleans:
enabled: yes   # → true
disabled: no   # → false
country: NO    # → false (!)  ← the Norway Problem

# Safe practice: quote strings that look like booleans
country: "NO"
enabled: "yes"

• Oktale heltall. I YAML 1.1 parses 010 som 8 (oktalt), ikke 10. Relevant for ting som filtillatelser.
• Tabulatorer vs mellomrom. YAML forbyr tabulatorer til innrykk. Bland inn én tabulator fra en kodeeditor, og filen din bryter stille ned eller kaster en kryptisk feil.
• Implicitte null-verdier. En tom verdi i YAML blir null. Lett å overse når man redigerer for hånd.
• String vs tall-tvetydighet. port: 8080 gir deg et heltall. version: 1.0 kan gi et float. Noen ganger vil du ha strengen "1.0". Sitér alltid når det betyr noe.

Praktisk beslutningsguide

Velg YAML når du:

• Skriver konfigurasjonsfiler som mennesker redigerer direkte: CI/CD, Kubernetes, Docker Compose, Ansible
• Filen vil ha kommentarer som forklarer innstillingene
• Flerlinjestrengverdier er vanlige
• Økosystemet du jobber i allerede bruker YAML (ikke kjemp mot konvensjonen)

Velg JSON når du:

• Sender eller mottar data via et API
• Data genereres og konsumeres programmatisk (ingen menneskelig redigering)
• Du trenger garantert parsekonsistens på tvers av forskjellige verktøy og språk
• Jobber i et økosystem som standardiserer på JSON: npm (package.json), VS Code (settings.json), Angular, TypeScript

Konvertering mellom de to

Trenger du å konvertere YAML-konfigurasjon til JSON for et verktøy som ikke forstår YAML? Bruk YAML til JSON-konverteren. Vil du den andre veien? JSON til YAML-konverteren tar seg av det. YAML Formatter er også nyttig når du limer inn YAML som har blitt skjevt. Og hvis YAML-en din ikke vil parse, forteller YAML Validator deg nøyaktig hvor problemet er.

Bunnlinjen

JSON og YAML utfyller hverandre — de konkurrerer ikke. Bruk JSON til datautveksling — API-er, programmatisk datalagring, serialisering. Bruk YAML til konfigurasjonsfiler som mennesker leser og redigerer. De fleste modne prosjekter bruker begge: package.json til avhengigheter, .github/workflows/*.yml til CI. Når du forstår hva hvert format er optimalisert for, blir valget åpenbart.