JSON vs YAML — Forskellene forklaret

Du har sikkert bemærket, at nogle projekter bruger .json-filer til konfiguration, mens andre bruger .yaml eller .yml. Begge formater repræsenterer strukturerede data. Begge er læsbare for mennesker. Hvad er den egentlige forskel, og hvornår skal du bruge det ene frem for det andet?

Jeg har brugt begge flittigt — JSON er min daglige driver til API'er og dataudveksling, YAML er mit go-to til Kubernetes-manifester, GitHub Actions og Docker Compose. De løser lignende problemer, men har meget forskellig personlighed.

Side om side: den samme konfiguration i begge formater

Her er et databasekonfigurationsobjekt 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 konfiguration i YAML:

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

YAML er tydeligt mindre rodet. Ingen anførselstegn om de fleste strenge, ingen krøllede parenteser, ingen kommaer. For en konfigurationsfil, som mennesker redigerer jævnligt, lægger den klarhed sig op. Men YAML opnår dette ved at være betydeligt mere kompleks under overfladen.

Hvor YAML skinner

• Konfigurationsfiler redigeret af mennesker. CI/CD-pipelines (GitHub Actions, GitLab CI), Kubernetes-manifester, Docker Compose, Ansible playbooks — alt YAML. Ikke tilfældigt — det er filer, som mennesker skriver i hånden.
• Kommentarer. YAML understøtter kommentarer med #. Det er enormt for konfigurationsfiler, hvor du vil forklare, hvorfor en indstilling er, som den er. JSON understøtter slet ikke kommentarer.
• Flerlinjede strenge. YAML har block scalars til indhold på flere linjer, der læses naturligt. JSON kræver \n-escape-sekvenser.
• Mindre visuelt rod. Ingen krav om at citere de fleste strenge, ingen afsluttende parenteser, ingen bekymringer om efterfølgende kommaer.
• Ankre og aliaser. YAML lader dig definere en værdi én gang og referere til den andre steder med &anchor og *alias — praktisk til DRY-konfigurationsfiler.

Hvor JSON vinder

• Strenghed. JSON har én gyldig repræsentation for en given datastruktur. YAML har et dusin måder at skrive det samme på, hvilket skaber inkonsistens på tværs af teams.
• Ingen indrykningsfælder. JSON bruger krøllede og firkantede parenteser. YAML bruger indrykning, hvilket betyder, at et enkelt fejlplaceret mellemrum lydløst kan ødelægge hele din konfiguration.
• Parseydelse. JSON-parsere er hurtige og enkle. YAML-parsere er komplekse — YAML 1.1 har notorisk vanskelige regler for implicit typetvang.
• Universelt biblioteksunderstøttelse. Alle sprog har en kamptestet, zero-dependency JSON-parser. YAML-biblioteker varierer i kvalitet og spec-overensstemmelse.
• Værktøjer. Linters, formatters, schemavalidatorer — JSON-værktøjer er mere modne og bredt tilgængelige.
• API-payloads. JSON er web-API'ernes universelle sprog. At sende YAML over HTTP ville være ukonventionelt og skabe gnidninger.

YAML-faldgruberne der vil brænde dig

YAML har nogle genuint overraskende adfærd, der har forårsaget rigtige produktionshændelser. De fleste af dem stammer fra de implicitte typeregler i YAML 1.1, som YAML 1.2 strammede op. Lær disse, inden du stoler på YAML til noget 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 heltal. I YAML 1.1 parses 010 som 8 (oktal), ikke 10. Relevant for ting som filtilladelser.
• Faner vs mellemrum. YAML forbyder faner til indrykning. Bland én fane ind fra en kodeeditor, og din fil bryder lydløst ned eller kaster en kryptisk fejl.
• Implicitte null-værdier. En tom værdi i YAML bliver null. Nemt at overse, når man redigerer i hånden.
• String vs tal-tvetydighed. port: 8080 giver dig et heltal. version: 1.0 kan give et float. Nogle gange vil du have strengen "1.0". Citér altid, når det har betydning.

Praktisk beslutningsguide

Vælg YAML, når du:

• Skriver konfigurationsfiler, som mennesker redigerer direkte: CI/CD, Kubernetes, Docker Compose, Ansible
• Filen vil have kommentarer, der forklarer indstillingerne
• Flerlinjede strengværdier er almindelige
• Det økosystem, du arbejder i, allerede bruger YAML (kæmp ikke mod konventionen)

Vælg JSON, når du:

• Sender eller modtager data via et API
• Data genereres og forbruges programmatisk (ingen menneskelig redigering)
• Du har brug for garanteret parsningskonsistens på tværs af forskellige værktøjer og sprog
• Arbejder i et økosystem, der standardiserer på JSON: npm (package.json), VS Code (settings.json), Angular, TypeScript

Konvertering mellem de to

Skal du konvertere YAML-konfiguration til JSON til et værktøj, der ikke forstår YAML? Brug YAML til JSON-konverteren. Vil du den anden vej? JSON til YAML-konverteren klarer det. YAML Formatter er også praktisk, når du indsætter YAML, der er blevet skæv. Og hvis din YAML ikke vil parse, fortæller YAML Validator dig præcis, hvor problemet er.

Bundlinjen

JSON og YAML supplerer hinanden — de konkurrerer ikke. Brug JSON til dataudveksling — API'er, programmatisk datalagring, serialisering. Brug YAML til konfigurationsfiler, som mennesker læser og redigerer. De fleste modne projekter bruger begge: package.json til afhængigheder, .github/workflows/*.yml til CI. Når du forstår, hvad hvert format er optimeret til, bliver valget indlysende.