Quelle structure JSON utiliser pour les paires de valeurs clés?

23

Quel format JSON est un meilleur choix pour les paires de valeurs clés et pourquoi?

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

Ou:

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

Ou:

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

La première variante semble plus compacte et plus «sémantiquement significative». La deuxième variante semble plus uniformément structurée, ce qui pourrait aider à la traiter. La 3e variante semble encore plus sémantique.

Les paires de valeurs clés seront utilisées pour attacher des données arbitraires à un autre élément. Les données doivent être sérialisées en JSON pour les arrondir à travers un système.

json

— boot4life
source

3

À moins que vous ne souhaitiez commander, pourquoi ne pas envisager {"key1": "value1", "key2": "value2"}?

— kennytm

4

JSON est déjà un dictionnaire (emboîtable).

— Kasey Speakman

1

Votre problème est que la description est suffisamment large pour dire que n'importe lequel de ces formats fonctionnera, et la vraie question est de savoir comment la rendre plus simple à utiliser, ce qui dépend des technologies utilisées par les clients.

— scriptin

Vous devriez utiliser le plus simple qui réponde à vos besoins, en espérant que ce sera la forme d'objet simple (# 3). Cependant, si vous recherchez encore plus d'options, vous pouvez utiliser deux tableaux en parallèle, un pour les clés et un pour les valeurs; qui sera à peu près aussi compact que possible tout en prenant en charge les clés d'objet et les clés en double (qui ne seraient pas prises en charge avec # 3).

— Erik Eidt

10

Que vous choisissiez la première ou la troisième option dépend de votre cas d'utilisation. Si vous modélisez de nombreuses instances différentes du même type de chose, choisissez la première. Par exemple, vous avez une liste de personnes. Si vous modélisez de nombreux attributs différents d'une chose, choisissez la troisième. Vous pouvez avoir des touches répétées dans le premier format, mais pas dans le troisième.

La deuxième option est terrible, et je n'ai pas encore trouvé de cas d'utilisation approprié. La raison pour laquelle c'est terrible, en plus d'être plus verbeux, est que pour le JSON à un niveau, il rompt la conversion automatique de la plupart des bibliothèques en dictionnaire / carte. Pour JSON profondément imbriqué, il casse l' interface de requête de type XPath .

Cela rend difficile de travailler avec. Et si vous ne connaissez pas vos clés au moment de la compilation, vous voudrez un dictionnaire ou une interface XPath, car vous ne pourrez pas le convertir en classe. Cela peut ne pas sembler être un gros problème maintenant, mais plus vous avez de format de données, plus il sera difficile de changer.

— Karl Bielefeldt
source

5

Le gros avantage de la deuxième option est qu'elle fonctionne avec des clés non string, en particulier des clés composites.

— CodesInChaos

1

La deuxième option est terrible et vous n'avez pas encore trouvé de cas d'utilisation? Un tableau de dictionnaires avec de nombreuses paires clé / valeur doit correspondre au format le plus courant pour la transmission de plusieurs objets.

— gnasher729

2

@ gnasher729, dans votre « format le plus commun » cas , les vraies clés sont sur le côté gauche: [{"key1": "value1", "key2": "value2"}]. Le deuxième format ici met la vraie clé sur le côté droit et utilise une autre clé appelée "Nom" pour vous pointer vers la vraie clé, ce qui rend extrêmement difficile l'analyse avec des outils standard.

— Karl Bielefeldt

Je vais vous donner celui-là, @CodesInChaos. Même là, cependant, il faudrait que ce soit un cas très spécial. Je n'en ai jamais vu le besoin dans la nature.

— Karl Bielefeldt

3

Désolé, mais c'est une mauvaise réponse. La 2e option est à la fois très utilisée et conseillée. Il permet une flexibilité des clés, il permet l'extension (avec plus de champs de valeur / métadonnées) sans casser les consommateurs, et il peut préserver l'ordre des éléments. De plus, les raisons invoquées sont fausses: il ne casse aucune "conversion automatique" (il respecte simplement la présentation de l'auteur sous forme de tableau) et il fonctionne très bien avec une interface de requête de type XPath. Le seul inconvénient est la verbosité accrue.

— Hejazzman

5

Le 3ème format est en général le meilleur. Cependant, voici un exemple de quelque chose qui convient au 1er format:

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

Ici, chaque objet fait référence à une chose distincte (et chaque objet utilise les mêmes clés que les autres, donc ils ne peuvent pas être fusionnés). Cependant, chaque objet de la liste est stocké en tant que { "username": "foo", "id": 1 }plutôt que [{ "username": "foo" }, { "id": 1 }]parce que 1) il est plus court et 2) il fait référence à une chose avec un nom d'utilisateur et un identifiant, pas une chose avec un nom d'utilisateur et une autre chose avec un identifiant.

Le problème avec la deuxième option est qu'elle devient très verbeuse à la fois en JSON et avec laquelle travailler. Cependant, il peut être utilisé si vous devez stocker des méta-informations sur la propriété. Un exemple:

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

Ici se mutableréfère à un cas hypothétique de savoir si vous pouvez modifier la propriété elle-même, pas l'objet parent. De telles méta-informations sont similaires à celles de JavaScript Object.defineProperty, qui stockent des informations "configurables", "énumérables" et "inscriptibles" sur une propriété.

— gcampbell
source

J'essayais d'utiliser le premier format pour certains JSON que j'envoyais à un point de terminaison C # REST et il ne se convertissait pas en objet dictionnaire. Le convertir au 3e format a clarifié cela.

— fizch

5

Vous dites que ce sont des paires clé / valeur. Dans ce cas, utilisez # 3: dictionnaire de paires clé / valeur.

S'il ne s'agit pas de paires clé / valeur, ne les appelez pas "clés" et "valeurs" et utilisez # 2, un tableau de dictionnaires au contenu arbitraire.

La structure n ° 1 est juste idiote, sauf si vous avez besoin de paires clé / valeur mais également de leur ordre. Ce que vous faites rarement.

— gnasher729
source

3

Mettez-vous à la place de la personne qui reçoit le json. Si je ne connais pas le nom de la clé, comment dois-je le récupérer avec le premier ou le dernier format? Vous pouvez parcourir le json bien sûr, mais comme les trois formats atteignent le même résultat, ce n'est qu'une question de syntaxe. Je pense que c'est la seule question pertinente: si vous connaissez les noms des clés, la première ou la dernière option est plus compacte, sinon le deuxième choix est plus compréhensible.

— JoulinRouge
source