JSON YAML — Cheat Sheet

Tag: json, yaml, serialization, api, configuration, data-formats

Livello: intermedio

TL;DR: Confronto rapido tra JSON (standard de facto per API REST e payload web) e YAML (standard per configurazioni CI/CD, Kubernetes e leggibilita umana).

Concetti chiave

JSON e rigoroso: chiavi tra doppi apici, niente commenti, niente virgole finali (trailing commas).

YAML e un superset di JSON: qualsiasi JSON valido e sintatticamente un documento YAML valido.

YAML si basa sull'indentazione a spazi; l'uso dei caratteri di tabulazione genera errori sintattici.

JSON supporta solo tipi base: string, number, boolean, null, object, array.

YAML supporta tipi avanzati: date native, set, casting esplicito e stringhe multiriga con controlli di newline.

YAML include ancore (&) e alias (*) con operatore merge (<<) per riusare blocchi di configurazione.

Il parsing di JSON e nativo e performante nei browser e nei runtime moderni come Node.js.

Il parsing di YAML e piu lento e vulnerabile a problemi di deserializzazione di oggetti arbitrari se non ristretto a safe load.

Domande tipiche e risposte pronte

Q: Quando scegli JSON rispetto a YAML e viceversa in un'architettura software?R: Uso JSON per lo scambio dati ad alto throughput, comunicazioni API REST e archiviazione dati dove contano velocita di parsing e interoperabilita nativa. Scelgo YAML per file di configurazione complessi, manifest Kubernetes e pipeline CI/CD perche supporta commenti, ancore e massima leggibilita umana.

Q: Come gestisci la sicurezza durante il parsing di YAML?R: Utilizzo sempre parser in modalita safe (come yaml.safe_load o configurazioni equivalenti) per impedire l'istanziazione automatica di classi o l'esecuzione remota di codice tramite tag personalizzati.

Q: Come risolvi la ridondanza nelle configurazioni YAML?R: Definisco un'ancora con &nome_ancora nel blocco comune e la richiamo tramite alias *nome_ancora, integrando le proprieta con l'operatore merge <<:.

Insidie e errori comuni

Inserire commenti in JSON causa errori di parsing nei parser conformi a RFC 8259.

Lasciare una virgola finale (trailing comma) dopo l'ultimo elemento in array o oggetti JSON.

Usare caratteri di tabulazione (\t) per indentare file YAML.

Interpretazione implicita di tipi in YAML: stringhe come yes, no, on, off vengono convertite in booleani se non racchiuse tra virgolette (Norwegian problem).

Stringhe numeriche come CAP o codici con zero iniziale (01234) interpretate come interi o ottali in YAML senza quoting esplicito.

Modificatori multiriga in YAML: | mantiene i newline finali (literal block), mentre > li ripiega in spazi singoli (folded block).

Snippet e comandi

{
  "service": "api-gateway",
  "port": 8080,
  "enabled": true,
  "tags": ["prod", "public"]
}

YAML

# Definizione base con ancore e multiriga
base_service: &base_config
  retries: 3
  timeout_ms: 5000

api_service:
  <<: *base_config
  port: 8080
  description: >
    Questo testo viene formattato
    su una singola riga continua.
  script: |
    echo "avvio"
    npm start

Bash

# Validazione e formattazione con jq (JSON) e yq (YAML)
jq . payload.json
yq eval -P config.yaml

Da ripassare

[ ] Differenza esatta tra operatori multiriga YAML |, |-, |+ e >, >-, >+

[ ] Regole di parsing delle ancore e alias con merge map (<<)

[x] Sintassi e tipi primitivi supportati dallo standard JSON RFC 8259

[x] Configurazione di safe loading dei file YAML nei runtime di backend

Jarvis Interviews
Jarvis