JSON appare in ruoli abbastanza differenti che vale la pena separarli: il formato è lo stesso ovunque, ma ciò che ogni caso d'uso ne necessita effettivamente differisce, e confondere uno per l'altro è una fonte comune di decisioni imbarazzanti (aggiungere commenti a un payload di API generato dalla macchina, o aspettarsi che una pipeline di log NDJSON sia parolata come un unico documento JSON).
Payload delle API REST
Il caso d'uso più comune per volume. Un corpo di richiesta e un corpo di
risposta sono ciascuno un documento JSON, Content-Type: application/json,
generato da un lato e consumato dall'altro senza alcun umano che lo legga
in mezzo. Nulla qui ha bisogno di commenti o comodità di modifica manuale;
ciò che serve è una grammatica senza ambiguità che tutte le lingue
parolino allo stesso modo, che è la vera forza di JSON. Un payload REST è
anche la forma per cui esiste il Validatore di JSON
Schema: controllare una risposta contro
il contratto che l'API dovrebbe rispettare, e vedere esattamente quale campo
lo viola e perché, prima che quel bug raggiunga il codice di produzione che
presuppone che il campo sia lì.
Configurazione delle applicazioni
package.json, tsconfig.json, composer.json, e decine di configurazioni
di strumenti oltre. Questo è il caso d'uso in cui la mancanza di commenti
di JSON costa effettivamente qualcosa: un'impostazione senza spiegazione
accanto, perché il formato non ha dove metterne. Alcuni strumenti aggirano
questo con una chiave // comment che nessuno legge programmaticamente,
altri passano a YAML o a un sovrainsieme di JSON (JSON5, JSONC) che
aggiunge i commenti. Vedi JSON vs YAML per il
compromesso completo; la versione breve è che i file di configurazione
modificati a mano spesso traggono beneficio dai commenti di YAML, mentre
la configurazione generata e consumata interamente dagli strumenti funziona
bene come JSON semplice.
NoSQL e database di documenti
MongoDB archivia i documenti come BSON, un formato binario che è un sovrainsieme del modello di dati di JSON, e restituisce JSON (o una sintassi shell simile a JSON) quando lo interroghi. CouchDB e la maggior parte degli archivi di documenti accettano e restituiscono JSON direttamente. L'appeal qui è strutturale: tutta la proposta di un database di documenti è archiviare i dati approssimativamente nella forma in cui la tua applicazione li usa già, invece di normalizzarli in righe e chiavi esterne prima, e il modello di oggetti e array di JSON è abbastanza vicino ai tipi nativi della maggior parte delle lingue affinché la traduzione sia quasi gratuita.
Righe di log e dati in streaming: NDJSON
Un singolo documento JSON non si trasmette bene: un parolatore generalmente ha bisogno di tutto prima di poter produrre un valore, perché un documento è valido solo quando la sua parentesi graffa finale arriva. Newline Delimited JSON (NDJSON) risolve questo facendo di ogni riga il proprio valore JSON completo e indipendente, quindi una pipeline di log, un topic Kafka, o un grande esportazione può essere elaborato riga per riga senza mantenere tutto il file in memoria. Il Convertitore JSON in NDJSON converte un array JSON in questo formato riga-per-record e viceversa, con recupero per un flusso che ha una riga malformata invece di fallire l'intero file per un singolo record errato.
Archiviazione del browser
localStorage e sessionStorage archiviano solo stringhe; qualsiasi cosa
strutturata entra come JSON.stringify(value) ed esce come
JSON.parse(memorizzato). Questo è anche dove il problema di precisione dei
numeri che Tipi di Dati JSON Spiegati tratta diventa
un bug reale invece di una curiosità: fare il round-trip di un grande ID intero
attraverso localStorage tramite il proprio JSON.parse del browser può
silenziosamente modificare il valore, che è esattamente la modalità di guasto
per cui gli strumenti di questo sito sono costruiti per evitarlo e segnalarlo
invece di riprodurlo.
Provare con i tuoi dati
Ogni strumento menzionato sopra funziona interamente nel tuo browser: nulla incollato nel Formatore JSON, nel convertitore NDJSON, o nel Validatore di Schema viene mai caricato da nessuna parte, il che conta maggiormente per esattamente il tipo di risposte API reali e file di configurazione di cui tratta questa pagina.