JSON: cos’è, a cosa serve, sintassi ed esempi pratici

JSON è un formato testuale usato per rappresentare e scambiare dati strutturati. Il nome significa JavaScript Object Notation, ma non indica un linguaggio di programmazione e non implica che debba essere utilizzato soltanto con JavaScript.

Lo incontri nelle risposte delle API, nei file di configurazione, nelle applicazioni web, nelle integrazioni tra software e in molti processi di importazione ed esportazione.

Un documento molto semplice può apparire così:

{
  "nome": "Tastiera",
  "prezzo": 49.90,
  "disponibile": true
}

A prima vista è solo testo con parentesi, virgolette e due punti. Quelle regole, però, permettono a programmi sviluppati con tecnologie differenti di interpretare la stessa struttura in modo prevedibile.

In questa guida vediamo cos’è JSON, come è fatto, quali regole sintattiche rispettare, come aprire e validare un file .json, come viene usato nelle API e quando conviene preferirlo a CSV o XML.

Cos’è JSON e perché viene usato per scambiare dati

JSON è un formato testuale per lo scambio di dati. Lo standard RFC 8259 lo descrive come leggero, basato sul testo e indipendente dal linguaggio di programmazione.

Questa indipendenza è uno dei motivi principali della sua diffusione.

Un’applicazione scritta in JavaScript può produrre i dati, un backend PHP può elaborarli e un servizio Python può leggerli senza che i tre sistemi debbano utilizzare lo stesso linguaggio.

Ciò che condividono è la rappresentazione dell’informazione.

Immagina un prodotto ecommerce:

Nome: Monitor
Prezzo: 199
Disponibile: sì
Categorie: Monitor, Hardware

Lo stesso contenuto può essere rappresentato così:

{
  "nome": "Monitor",
  "prezzo": 199,
  "disponibile": true,
  "categorie": ["Monitor", "Hardware"]
}

La struttura non dipende più dalla disposizione grafica di una pagina o dalle colonne di un foglio: ogni informazione possiede un nome e un valore che il software può interpretare.

Cosa significa JavaScript Object Notation

La sigla JSON deriva da JavaScript Object Notation.

L’origine è collegata alla sintassi degli oggetti di JavaScript, ma il formato si è affermato come tecnologia indipendente. La documentazione di JSON.org lo presenta infatti come un formato testuale utilizzabile con numerosi linguaggi di programmazione.

Questa distinzione evita un equivoco frequente.

Il seguente contenuto:

{
  "nome": "Marco",
  "eta": 35
}

è valido, ma non esegue alcuna istruzione. Non contiene condizioni, funzioni, cicli o logica applicativa: descrive semplicemente dei dati.

Non è un linguaggio di programmazione

Un linguaggio di programmazione permette di esprimere operazioni e comportamenti.

Puoi stabilire, per esempio:

se il prezzo è maggiore di 100 → applica uno sconto

Un formato di rappresentazione dei dati non esegue questa logica.

Può invece contenere i valori sui quali lavorerà il programma:

{
  "prezzo": 120,
  "sconto": 10
}

Sarà poi l’applicazione a decidere cosa fare con queste informazioni.

È quindi più corretto parlare di formato per rappresentare dati, non di linguaggio con cui sviluppare un’applicazione.

File .json, application/json e UTF-8

Quando il contenuto viene salvato su disco, l’estensione comune è:

.json

Per esempio:

config.json

oppure:

prodotti.json

Sul web il media type standard è:

application/json

RFC 8259 registra sia application/json sia l’estensione .json.

Per lo scambio tra sistemi aperti c’è inoltre un dettaglio tecnico importante: la codifica da utilizzare è UTF-8.

Questo riduce i problemi di interoperabilità quando i dati contengono lettere accentate, simboli o caratteri appartenenti ad alfabeti differenti.

Se stai progettando un nuovo flusso destinato a comunicare fra sistemi diversi, UTF-8 è quindi il riferimento corretto.

Come è fatto JSON: oggetti, array e tipi di dato

Il modello fondamentale si basa soprattutto su due strutture:

• oggetti, che associano nomi a valori;
• array, che organizzano sequenze ordinate di valori.

Le due strutture possono contenersi reciprocamente, permettendo di rappresentare sia informazioni molto semplici sia gerarchie articolate.

Considera questo esempio:

{
  "id": 42,
  "nome": "Notebook",
  "disponibile": true,
  "prezzo": 899.90,
  "categorie": ["Computer", "Portatili"],
  "specifiche": {
    "ram": "16 GB",
    "storage": "512 GB",
    "wifi": true
  }
}

Dentro un unico oggetto troviamo numeri, testo, un booleano, un array e un altro oggetto annidato.

È proprio la possibilità di conservare queste relazioni gerarchiche a rendere il formato particolarmente pratico nelle applicazioni e nelle API.

Oggetti e coppie chiave-valore

Un oggetto è delimitato dalle parentesi graffe:

{
}

Al suo interno puoi inserire membri formati da un nome e un valore:

{
  "nome": "Notebook"
}

La parte:

"nome"

è il nome della proprietà.

La parte:

"Notebook"

è il valore.

I due elementi sono separati dai due punti:

:

Quando l’oggetto contiene più proprietà, le coppie vengono separate da virgole:

{
  "nome": "Notebook",
  "prezzo": 899.90,
  "disponibile": true
}

Un dettaglio meno evidente riguarda i nomi duplicati.

RFC 8259 indica che i nomi all’interno dello stesso oggetto dovrebbero essere univoci. Una struttura del genere può quindi creare problemi:

{
  "prezzo": 100,
  "prezzo": 120
}

Alcuni parser possono conservare l’ultimo valore, mentre altri possono comportarsi diversamente.

Anche se un determinato software accetta chiavi duplicate, non è una buona base per costruire uno scambio di dati interoperabile.

Array e strutture annidate

Un array utilizza parentesi quadre:

[
  "rosso",
  "verde",
  "blu"
]

A differenza delle proprietà di un oggetto, i suoi elementi formano una sequenza ordinata.

Puoi avere anche array di oggetti:

[
  {
    "id": 1,
    "nome": "Mouse"
  },
  {
    "id": 2,
    "nome": "Tastiera"
  }
]

È un modello molto comune quando un’API restituisce una lista di risorse.

Gli array possono inoltre essere inseriti all’interno di un oggetto:

{
  "categoria": "Accessori",
  "prodotti": [
    {
      "id": 1,
      "nome": "Mouse"
    },
    {
      "id": 2,
      "nome": "Tastiera"
    }
  ]
}

In questo caso la proprietà prodotti contiene un array e ogni elemento dell’array è a sua volta un oggetto.

È così che il formato riesce a modellare strutture gerarchiche senza costringerti ad appiattire tutto in righe e colonne.

Stringhe, numeri, booleani e null

I valori ammessi comprendono:

• stringhe;
• numeri;
• oggetti;
• array;
• true;
• false;
• null.

Una stringa deve essere racchiusa tra doppi apici:

{
  "nome": "Monitor"
}

Un numero non va invece racchiuso tra virgolette:

{
  "prezzo": 199.90
}

Questi due casi non sono equivalenti:

{
  "quantita": 10
}

{
  "quantita": "10"
}

Nel primo caso il valore è numerico. Nel secondo è una stringa contenente i caratteri 1 e 0.

Anche i booleani hanno una sintassi precisa:

{
  "disponibile": true,
  "in_offerta": false
}

true e false sono minuscoli e non hanno virgolette.

null rappresenta invece un valore nullo:

{
  "secondo_nome": null
}

Non va confuso con una stringa vuota:

{
  "secondo_nome": ""
}

né con:

{
  "secondo_nome": "null"
}

Sono tre valori differenti.

C’è inoltre un limite pratico da considerare con i numeri. La grammatica permette di rappresentare valori molto grandi, ma il software che li riceve può avere limiti di precisione.

In JavaScript, per esempio, un intero molto grande può perdere precisione quando viene convertito in un normale Number.

Per identificativi lunghi sui quali non devono essere eseguiti calcoli, una stringa può risultare più sicura, se il contratto tra i sistemi lo prevede.

Sintassi JSON: le regole per scrivere dati validi

La sintassi è relativamente semplice, ma bastano piccoli errori per rendere il documento non valido.

Questo esempio è corretto:

{
  "nome": "Mouse",
  "prezzo": 24.90,
  "disponibile": true,
  "colori": ["nero", "bianco"]
}

Un parser riesce a interpretarlo perché parentesi, nomi, valori, virgole e virgolette rispettano la grammatica prevista.

Doppi apici, due punti, virgole e parentesi

I nomi delle proprietà devono essere racchiusi tra doppi apici:

{
  "nome": "Tastiera"
}

Questo invece non è valido:

{
  nome: "Tastiera"
}

Nome e valore sono separati dai due punti:

"nome": "Tastiera"

Le coppie successive sono separate da virgole:

{
  "nome": "Tastiera",
  "prezzo": 49.90
}

Le parentesi hanno due funzioni differenti:

{ } → oggetto
[ ] → array

Per esempio:

{
  "colori": ["nero", "bianco"]
}

Spazi e interruzioni di riga usati per indentare il documento non modificano la struttura, purché non siano inseriti all’interno di una stringa.

Questo:

{"nome":"Mouse","prezzo":24.9}

e questo:

{
  "nome": "Mouse",
  "prezzo": 24.9
}

rappresentano gli stessi dati.

La seconda forma è semplicemente più leggibile.

Trailing comma, apici singoli e commenti: gli errori più comuni

Un errore frequente consiste nel lasciare una virgola dopo l’ultimo elemento.

Questo non è valido:

{
  "nome": "Mouse",
  "prezzo": 24.90,
}

La virgola dopo 24.90 è una trailing comma e la grammatica standard non la consente.

Un altro errore è usare apici singoli:

{
  'nome': 'Mouse'
}

La sintassi può ricordare quella ammessa da alcuni linguaggi, ma stringhe e nomi dei membri devono utilizzare doppi apici.

Neppure i commenti tradizionali fanno parte dello standard:

{
  "nome": "Mouse", // nome prodotto
  "prezzo": 24.90
}

Lo stesso vale per:

/* commento */

Se un software accetta commenti, trailing comma o altre estensioni, sta utilizzando una variante o un parser più permissivo. Non è quindi prudente presumere che lo stesso documento funzioni ovunque.

Non sono ammessi neppure alcuni valori tipici di JavaScript:

undefined
NaN
Infinity

Per esempio:

{
  "valore": undefined
}

non può essere interpretato da un parser conforme allo standard.

Chiavi duplicate e problemi di interoperabilità

Un documento può sembrare corretto e funzionare in un’applicazione, ma produrre risultati differenti altrove.

Considera:

{
  "stato": "bozza",
  "stato": "pubblicato"
}

Quale dei due valori dovrebbe prevalere?

Il punto è proprio questo: parser differenti possono prendere decisioni differenti.

Per dati destinati allo scambio conviene quindi usare nomi univoci:

{
  "stato": "pubblicato"
}

Un’altra cautela riguarda l’ordine delle proprietà degli oggetti.

Se la posizione è parte dell’informazione, non farei affidamento sull’ordine delle chiavi per comunicarla fra sistemi differenti. Per una sequenza esplicitamente ordinata, l’array è la struttura più adatta.

C’è infine una precisazione che spesso viene omessa: un testo conforme allo standard non deve necessariamente iniziare con { o [.

RFC 8259 definisce infatti un JSON text come un valore serializzato. Possono quindi essere validi anche:

"ciao"

42

true

null

Nella pratica API e applicazioni utilizzano molto spesso oggetti o array come valore principale perché permettono di trasportare strutture più ricche, ma non sono le uniche possibilità previste dallo standard.

Come aprire, leggere e formattare un file JSON

Un file .json contiene testo.

Può quindi essere aperto con qualsiasi editor capace di leggere un normale documento testuale.

La vera differenza tra gli strumenti riguarda quanto facilmente consentono di:

• indentare la struttura;
• evidenziare chiavi e valori;
• comprimere o espandere oggetti;
• individuare errori;
• lavorare con file molto grandi.

Aprirlo con un editor di testo o di codice

Per un documento piccolo può bastare un normale editor di testo.

Se devi modificarlo, un editor di codice è normalmente più comodo grazie a syntax highlighting, indentazione automatica e controlli della struttura.

Considera:

{
  "cliente": {
    "id": 1204,
    "nome": "Anna",
    "ordini": [
      {
        "id": 9001,
        "totale": 72.50
      },
      {
        "id": 9002,
        "totale": 19.90
      }
    ]
  }
}

Diventa molto più semplice da ispezionare quando l’editor distingue visivamente parentesi, chiavi, stringhe e numeri.

Anche alcuni browser visualizzano e formattano automaticamente questo tipo di risposta, soprattutto quando proviene da un endpoint web.

Per una verifica rapida può essere sufficiente. Se devi però modificare un file importante, preferirei lavorare su una copia locale con un editor che renda chiare le modifiche effettuate.

Documento formattato e minificato

Una versione formattata, o pretty printed, utilizza spazi e ritorni a capo per migliorare la leggibilità:

{
  "id": 1,
  "nome": "Mouse",
  "prezzo": 24.90
}

La stessa informazione può essere minificata:

{"id":1,"nome":"Mouse","prezzo":24.90}

La struttura logica non cambia.

La forma minificata elimina i caratteri non necessari e può ridurre leggermente la quantità di testo trasferito. La versione indentata è invece più pratica durante sviluppo, debugging e revisione manuale.

In sintesi:

lettura e debugging → formato leggibile

trasferimento → eventualmente minificato

Con payload molto grandi, però, eliminare gli spazi non risolve problemi strutturali.

Se devi elaborare milioni di record o un flusso continuo di dati, può essere più importante adottare tecniche di streaming o un formato pensato per quel tipo di elaborazione.

Come controllare se un JSON è valido

La validazione sintattica risponde a una domanda precisa:

questo testo rispetta la grammatica prevista?

Per esempio:

{
  "nome": "Mouse",
  "prezzo": 24.90
}

può essere interpretato normalmente.

Questo invece contiene un errore:

{
  "nome": "Mouse",
  "prezzo": 24.90,
}

Puoi verificare la sintassi con il parser del linguaggio che stai utilizzando, un editor dotato di validazione oppure uno strumento dedicato.

In JavaScript, per esempio, JSON.parse() restituisce il valore risultante quando riesce a interpretare la stringa e genera un errore di sintassi quando il contenuto non è valido.

C’è però una cautela concreta: non incollare automaticamente informazioni riservate in validator online casuali.

Un file può contenere:

• token API;
• email;
• dati personali;
• configurazioni interne;
• identificativi;
• chiavi;
• informazioni commerciali.

Per contenuti sensibili è preferibile utilizzare strumenti locali o servizi di cui hai verificato trattamento e destinazione dei dati.

Inoltre:

sintassi valida ≠ dati corretti

Questo documento è sintatticamente corretto:

{
  "email": "banana",
  "eta": -600
}

La struttura è interpretabile, ma i valori potrebbero essere incompatibili con le regole dell’applicazione.

Per controllare anche struttura e vincoli occorre un livello ulteriore, come JSON Schema.

JSON nelle API: come vengono scambiati i dati

Uno degli scenari più comuni è la comunicazione attraverso API.

Una API definisce il modo in cui due componenti software possono interagire. Il formato dei dati è un livello differente.

La distinzione è importante:

API = interfaccia e regole di comunicazione

JSON = possibile rappresentazione dei dati

Non sono sinonimi.

Se vuoi vedere questa relazione in un caso concreto, la guida alle WordPress REST API mostra come un client possa richiedere contenuti a WordPress e ricevere informazioni strutturate attraverso endpoint HTTP.

Esempio di richiesta e risposta

Immagina un servizio con questo endpoint:

GET /api/prodotti/42

Il client chiede il prodotto con ID 42.

Il server potrebbe rispondere con:

{
  "id": 42,
  "nome": "Monitor 27 pollici",
  "prezzo": 199.90,
  "disponibile": true
}

L’header della risposta può indicare:

Content-Type: application/json

Il client sa così quale rappresentazione sta ricevendo e può convertirla nelle strutture utilizzate dall’applicazione.

Una richiesta POST può fare il percorso opposto.

Il client invia:

{
  "nome": "Webcam",
  "prezzo": 59.90
}

e il server elabora quei valori secondo le regole definite dall’API.

Il vantaggio non è soltanto la leggibilità: struttura, tipi e gerarchie possono essere interpretati automaticamente da software differenti.

JSON e REST non sono la stessa cosa

REST e JSON vengono spesso nominati insieme, ma indicano concetti differenti.

REST descrive uno stile architetturale per sistemi distribuiti. Il secondo è invece un formato per rappresentare dati.

Una REST API può utilizzarlo, ma REST non obbliga un servizio a scegliere questa rappresentazione.

Allo stesso modo, un file .json può esistere senza alcuna REST API: per esempio come configurazione locale, archivio o messaggio.

Quindi:

REST ≠ JSON

Più correttamente:

REST API → può scambiare → dati in formato JSON

La distinzione evita di trattare un formato di dati come se fosse un protocollo di rete.

JSON.parse() e JSON.stringify() in JavaScript

In JavaScript due metodi ricorrono continuamente.

JSON.parse() converte una stringa valida in un valore JavaScript:

const testo = '{"nome":"Mouse","prezzo":24.9}';

const prodotto = JSON.parse(testo);

console.log(prodotto.nome);

Il risultato della proprietà nome sarà:

Mouse

La documentazione MDN di JSON.parse() descrive anche il parametro reviver, utile per trasformare i valori durante il parsing.

Il percorso inverso utilizza JSON.stringify():

const prodotto = {
  nome: "Mouse",
  prezzo: 24.9
};

const testo = JSON.stringify(prodotto);

La variabile testo conterrà:

{"nome":"Mouse","prezzo":24.9}

La documentazione MDN di JSON.stringify() mostra anche come controllare proprietà, trasformazioni e indentazione.

Qui emerge una distinzione fondamentale: un oggetto JavaScript e una stringa serializzata non sono la stessa cosa.

L’oggetto è una struttura presente nella memoria del programma.

La stringa è una rappresentazione testuale che può essere salvata o trasmessa.

JSON Schema: controllare struttura e vincoli

Verificare che la sintassi sia corretta non basta sempre.

Se un’applicazione si aspetta un prodotto, potresti voler imporre regole come:

• nome deve esistere;
• prezzo deve essere un numero;
• il prezzo non può essere negativo;
• disponibile deve essere un booleano;
• non sono ammesse proprietà impreviste.

È questo il problema affrontato da JSON Schema.

La specifica JSON Schema definisce un sistema per descrivere la struttura prevista di un documento e applicare vincoli ai suoi valori.

Sintassi valida e conformità allo schema sono cose diverse

Considera:

{
  "nome": "Mouse",
  "prezzo": "gratis"
}

La sintassi è perfettamente valida.

Se però il sistema richiede che prezzo sia numerico, quel documento non soddisfa il contratto applicativo.

Uno schema può esprimere proprio questo vincolo.

La distinzione è:

validazione sintattica → controlla la grammatica

validazione tramite schema → controlla struttura e vincoli

Uno schema non può comunque stabilire automaticamente se un’informazione sia vera nel mondo reale.

Se scrivi:

{
  "prezzo": 9.99
}

ma il prezzo corretto è 29.99, la struttura può essere conforme e il dato comunque sbagliato.

La validazione tecnica non sostituisce la qualità dell’informazione.

Un esempio semplice di JSON Schema

Uno schema essenziale per un prodotto potrebbe essere:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "nome": {
      "type": "string"
    },
    "prezzo": {
      "type": "number",
      "minimum": 0
    },
    "disponibile": {
      "type": "boolean"
    }
  },
  "required": ["nome", "prezzo"],
  "additionalProperties": false
}

In termini pratici stabilisce che:

• il valore principale deve essere un oggetto;
• nome deve essere una stringa;
• prezzo deve essere un numero uguale o superiore a zero;
• disponibile, se presente, deve essere un booleano;
• nome e prezzo sono obbligatori;
• non sono ammesse proprietà diverse da quelle previste.

Questo documento può soddisfare le regole:

{
  "nome": "Mouse",
  "prezzo": 24.90,
  "disponibile": true
}

Questo invece no:

{
  "nome": "Mouse",
  "prezzo": -10
}

Non perché sia sintatticamente malformato, ma perché viola il vincolo minimum.

È una differenza particolarmente utile quando più applicazioni devono condividere un contratto sui dati.

JSON, CSV e XML: quale formato scegliere

JSON non sostituisce automaticamente tutti gli altri formati.

La scelta dipende da forma dei dati, strumenti coinvolti, interoperabilità richiesta e modalità di elaborazione.

Formato	Punto di forza	Ideale quando	Limite da considerare
JSON	strutture gerarchiche, tipi di valore, integrazione applicativa	API, configurazioni e dati strutturati	più verboso di una semplice tabella
CSV	semplicità per righe e colonne	dataset tabellari, import/export, fogli di calcolo	le gerarchie richiedono appiattimenti o convenzioni
XML	struttura gerarchica ricca e markup estensibile	documenti, standard e sistemi basati su XML	sintassi spesso più verbosa nei payload applicativi

Non esiste quindi un “formato migliore” in assoluto.

JSON vs CSV: strutture annidate o dati tabellari

CSV è particolarmente efficace quando le informazioni sono naturalmente tabellari.

Per esempio:

id,nome,prezzo
1,Mouse,24.90
2,Tastiera,49.90

La struttura è lineare:

riga → colonne

Se devi lavorare con questo tipo di dataset, il formato è spesso molto pratico. Nella guida ai file CSV trovi anche problemi reali da controllare durante importazione ed esportazione, come delimitatori, encoding e conversioni automatiche dei valori.

Quando invece un record contiene gerarchie, array o oggetti annidati, un modello strutturato diventa più naturale.

Immagina un prodotto con immagini e varianti:

{
  "id": 1,
  "nome": "T-shirt",
  "immagini": [
    "fronte.jpg",
    "retro.jpg"
  ],
  "varianti": [
    {
      "taglia": "M",
      "colore": "nero"
    },
    {
      "taglia": "L",
      "colore": "nero"
    }
  ]
}

In CSV dovresti decidere come appiattire quelle relazioni.

Potresti creare più righe, più file o convenzioni all’interno delle celle. Sono soluzioni possibili, ma il modello tabellare non rappresenta direttamente la gerarchia.

La decisione pratica può essere riassunta così:

tabella semplice → CSV è spesso più naturale

struttura gerarchica o payload applicativo → JSON è spesso più naturale

JSON vs XML: dati, markup e requisiti diversi

Anche XML consente di rappresentare strutture gerarchiche.

Un esempio essenziale:

<prodotto>
  <nome>Mouse</nome>
  <prezzo>24.90</prezzo>
</prodotto>

La stessa informazione può essere rappresentata così:

{
  "nome": "Mouse",
  "prezzo": 24.90
}

Per molti payload applicativi la seconda forma tende a essere più compatta e dispone direttamente di tipi come numeri, booleani e null.

XML offre però caratteristiche proprie, tra cui attributi, namespace e un ecosistema consolidato di standard documentali.

Non lo considererei quindi un “vecchio JSON”.

Sono modelli differenti che possono risolvere problemi sovrapposti, ma non identici. Se vuoi approfondire l’altro formato, trovi una guida dedicata a XML e al suo utilizzo con WordPress.

In un progetto nuovo sceglierei in base al contratto che i sistemi devono rispettare, non alla popolarità del momento.

JSON e JSON-LD non sono la stessa cosa

JSON-LD utilizza questa sintassi per rappresentare Linked Data, cioè dati collegati semanticamente.

Un blocco può apparire così:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titolo dell'articolo"
}

Riconosci oggetti, proprietà e stringhe, ma elementi come:

@context
@type

appartengono al modello JSON-LD.

Quindi:

un documento JSON-LD è basato su JSON

ma:

un normale documento JSON non è automaticamente JSON-LD

La distinzione è particolarmente importante in ambito SEO, perché JSON-LD viene spesso usato per inserire dati strutturati nelle pagine web. La guida allo schema markup e ai dati strutturati approfondisce questo utilizzo e il rapporto con Schema.org e Google.

I due termini non vanno quindi usati come sinonimi.

Quando conviene usare JSON e quando scegliere un altro formato

Il formato è particolarmente adatto quando devi gestire dati strutturati leggibili sia dalle applicazioni sia, con relativa facilità, dalle persone.

Lo sceglierei soprattutto per:

• payload di API;
• file di configurazione;
• scambio di dati tra applicazioni;
• oggetti con proprietà e strutture annidate;
• integrazioni tra sistemi sviluppati con tecnologie differenti;
• informazioni che devono mantenere una gerarchia esplicita.

Ha meno senso sceglierlo automaticamente in scenari diversi.

Per un grande elenco piatto destinato a essere aperto in un foglio di calcolo, CSV può essere più comodo.

Per documenti o standard che richiedono caratteristiche specifiche di XML, convertire tutto senza una ragione concreta può invece aumentare la complessità.

Per contenuti binari come immagini, video o archivi, un file testuale non è normalmente il contenitore ideale del dato grezzo. Può conservarne metadati o riferimenti, ma codificare grandi quantità di binario all’interno di stringhe aumenta dimensione e complessità.

Anche il volume conta.

Un enorme array con milioni di elementi può essere formalmente corretto ma poco pratico se l’applicazione deve caricarlo interamente prima di iniziare l’elaborazione. Per flussi molto grandi o continui possono servire tecniche di streaming, formati record-oriented o protocolli progettati per requisiti differenti.

La domanda più utile non è quindi:

“JSON è moderno?”

ma:

“la struttura e il modo in cui questi dati devono viaggiare corrispondono bene a questo modello?”

Se la risposta è sì, rimane una soluzione semplice, interoperabile e ampiamente supportata.

Conclusione

JSON è uno dei formati più diffusi per lo scambio di dati perché combina struttura, semplicità e supporto trasversale tra linguaggi e piattaforme.

Per utilizzarlo correttamente, però, non basta riconoscere parentesi graffe e coppie chiave-valore.

I punti da ricordare sono soprattutto questi:

• rappresenta dati, non esegue programmi;
• oggetti e array permettono di costruire strutture annidate;
• stringhe, numeri, booleani e null sono valori differenti;
• doppi apici, virgole e parentesi devono rispettare una sintassi precisa;
• un documento sintatticamente valido può comunque contenere informazioni sbagliate;
• JSON Schema può aggiungere controlli sulla struttura;
• il formato viene spesso usato nelle API, ma non coincide con API o REST;
• JSON-LD ha uno scopo semantico specifico;
• CSV, XML e JSON rispondono a esigenze differenti.

Se devi scegliere come rappresentare un dataset, partirei quindi dalla forma reale dell’informazione.

Dati tabellari semplici? Valuta CSV. Strutture gerarchiche e integrazioni applicative? JSON è spesso la scelta più naturale. Requisiti documentali o standard basati su XML? Mantieni il formato che risolve meglio quel problema.

Il formato corretto non è quello con il nome più familiare, ma quello che conserva struttura e significato senza costringere i sistemi a inventare continuamente eccezioni per interpretare i dati.