Quale struttura JSON da utilizzare per le coppie chiave-valore?


23

Quale formato JSON è una scelta migliore per le coppie chiave-valore e perché?

[{"key1": "value1"}, {"key2": "value2"}]

O:

[{"Name": "key1", "Value": "value1"}, {"Name": "key2", "Value": "value2"}]

O:

{"key1": "value1", "key2": "value2"}

La prima variante sembra più compatta e più "semanticamente significativa". La seconda variante sembra strutturata in modo più uniforme, il che potrebbe aiutare a elaborarla. La terza variante sembra ancora più semantica.

Le coppie di valori chiave verranno utilizzate per allegare dati arbitrari ad altri elementi. I dati devono essere serializzati come JSON per arrotondarli attraverso un sistema.


3
A meno che non sia necessario ordinare, perché non considerare {"key1": "value1", "key2": "value2"}?
kennytm,

4
JSON è già un dizionario (annidabile).
Kasey Speakman,

1
Il tuo problema è che la descrizione è abbastanza ampia da dire che uno qualsiasi di quei formati funzionerà, e la vera domanda è come renderne più semplice il consumo, che dipende dalle tecnologie utilizzate dai clienti.
scriptin

Dovresti usare il più semplice che soddisfi le tue esigenze, si spera che sia la forma dell'oggetto semplice (n. 3). Tuttavia, se stai cercando ancora più opzioni, puoi utilizzare due array in parallelo, uno per le chiavi e uno per i valori; sarà praticamente il più compatto possibile pur continuando a supportare chiavi oggetto e chiavi duplicate (che non sarebbero supportate con il n. 3).
Erik Eidt,

Risposte:


10

La scelta della prima o della terza opzione dipende dal caso d'uso. Se stai modellando molte istanze diverse dello stesso tipo di cose, scegli la prima. Ad esempio, hai un elenco di persone. Se stai modellando molti attributi diversi di una cosa, scegli la terza. Puoi avere tasti ripetuti nel primo formato, ma non nel terzo.

La seconda opzione è terribile e non ho ancora trovato un caso d'uso appropriato. Il motivo per cui è terribile, oltre ad essere più dettagliato, è che per JSON a livello singolo, interrompe la conversione automatica della maggior parte delle librerie in un dizionario / mappa. Per JSON profondamente annidato, interrompe l' interfaccia di query simile a XPath .

Questo rende doloroso lavorare. E se non conosci le tue chiavi al momento della compilazione, vorrai un dizionario o un'interfaccia XPath, perché non sarai in grado di convertirlo in una classe. Potrebbe non sembrare un grosso problema ora, ma più a lungo hai un formato di dati, più difficile sarà cambiare.


5
Il grande vantaggio della seconda opzione è che funziona con chiavi non stringa, in particolare chiavi composte.
CodesInChaos

1
La seconda opzione è terribile e devi ancora trovare un caso d'uso? La matrice di dizionari con molte coppie chiave / valore deve riguardare il formato più comune per la trasmissione di più oggetti.
gnasher729,

2
@ gnasher729, nel tuo caso "più comune formato" i tasti reali sono tutti sul lato sinistro: [{"key1": "value1", "key2": "value2"}]. Il secondo formato qui è mettere la chiave reale sul lato destro e usare un'altra chiave chiamata "Nome" per indicarti la chiave reale, rendendo estremamente difficile analizzare gli strumenti standard.
Karl Bielefeldt,

Ti darò quello, @CodesInChaos. Anche lì, però, dovrebbe essere un caso molto speciale. Non ne ho mai visto il bisogno in natura.
Karl Bielefeldt,

3
Scusa, ma questa è una cattiva risposta. La seconda opzione è sia molto comunemente usata che consigliata. Consente la flessibilità delle chiavi, consente l'estensione (con più campi valore / metadati) senza interrompere i consumatori e può preservare l'ordine degli elementi. Inoltre, le ragioni fornite sono false: non interrompe alcuna "conversione automatica" (rispetta semplicemente la presentazione dell'autore come array) e funziona perfettamente con un'interfaccia di query simile a XPath. L'unico aspetto negativo è la maggiore verbosità.
Hejazzman,

5

Il terzo formato è in genere il migliore. Tuttavia, ecco un esempio di qualcosa adatto al 1 ° formato:

[{
  "username": "foo",
  "id": 1
}, {
  "username": "bar",
  "id": 2
}, {
  "username": "baz",
  "id": 3
}]

Qui ogni oggetto si riferisce a una cosa separata (e ogni oggetto usa le stesse chiavi degli altri, quindi non possono essere uniti). Tuttavia, ogni oggetto nell'elenco viene archiviato come { "username": "foo", "id": 1 }anziché [{ "username": "foo" }, { "id": 1 }]perché 1) è più corto e 2) si riferisce a una cosa con un nome utente e un ID, non una cosa con un nome utente e un'altra cosa con un ID.

Il problema con la seconda opzione è che diventa molto prolisso sia come JSON che con cui lavorare. Tuttavia, potrebbe essere utilizzato se è necessario memorizzare meta-informazioni sulla proprietà. Un esempio:

{
  "key": "foo",
  "value": 1,
  "mutable": true
}

Qui si mutablefa riferimento a un ipotetico caso in cui è possibile modificare la proprietà stessa, non l'oggetto principale. Meta-informazioni come questa sono simili a quelle di JavaScript Object.defineProperty, che memorizzano informazioni "configurabili", "enumerabili" e "scrivibili" su una proprietà.


Stavo cercando di utilizzare il primo formato per alcuni JSON che stavo inviando a un endpoint CEST REST e non si stava convertendo in un oggetto dizionario. La conversione nel terzo formato lo ha chiarito.
Fizch

5

Dici che queste sono coppie chiave / valore. In tal caso, utilizzare # 3: dizionario delle coppie chiave / valore.

Se queste non sono coppie chiave / valore, non chiamarle "chiavi" e "valori" e utilizzare # 2, una matrice di dizionari con contenuti arbitrari.

La struttura n. 1 è solo stupida a meno che non siano necessarie coppie chiave / valore ma anche il loro ordine. Cosa che fai raramente.


3

Mettiti nei panni della persona che riceve il json. Se non conosco il nome della chiave, come dovrei recuperarlo con il primo o l'ultimo formato? Ovviamente puoi passare da un json all'altro, ma poiché tutti e tre i formati ottengono lo stesso risultato è solo una questione di sintassi. Penso che questa sia l'unica domanda significativa: se conosci i nomi delle chiavi, la prima o l'ultima opzione sono più compatte, altrimenti la seconda scelta è più comprensibile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.