web-dev-qa-db-ja.com

キーと値のペアに使用するJSON構造は何ですか？

キーと値のペアにはどのJSON形式が適していますか？その理由は？

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

または：

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

または：

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

最初のバリアントは、よりコンパクトで、「意味的に意味がある」ように見えます。 2番目のバリアントは、より均一に構造化されているように見え、処理に役立つ場合があります。 3番目のバリアントはさらにセマンティックに見えます。

キーと値のペアは、他のアイテムに任意のデータを添付するために使用されます。システム全体でデータを丸めるには、データをJSONとしてシリアル化する必要があります。

json
27
boot4life

最初のオプションと3番目のオプションのどちらを選択するかは、ユースケースによって異なります。同じタイプのものの多くの異なるインスタンスをモデリングしている場合は、最初のものを選択します。たとえば、ユーザーのリストがあるとします。 1つのものの多くの異なる属性をモデル化する場合は、3番目のものを選択します。最初の形式ではキーを繰り返すことができますが、3番目の形式ではできません。

2番目のオプションはひどいもので、適切な使用例をまだ見つけていません。それがひどい理由は、より冗長であることに加えて、単一レベルのJSONの場合、ほとんどのライブラリーの辞書/マップへの自動変換を壊すためです。深くネストされたJSONの場合、それは XPath-like クエリインターフェイスを壊します。

これにより、作業が面倒になります。コンパイル時にキーがわからない場合は、クラスに変換できないため、辞書またはXPathインターフェイスが必要になります。今は大したことではないように見えるかもしれませんが、データ形式が長いほど、変更が難しくなります。

11
Karl Bielefeldt

これらはキー/値のペアであると言います。その場合は、＃3：辞書のキーと値のペアを使用します。

これらがnotキー/値のペアである場合、それらを「キー」および「値」と呼ばず、任意の内容の辞書の配列である＃2を使用しないでください。

構造＃1は、キーと値のペアだけでなく、それらの順序も必要としない限り、ほとんどありません。あなたがめったにしないこと。

6
gnasher729

3番目の形式は一般的にが最適です。ただし、これは1番目の形式に適した例です。

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

ここで、各オブジェクトは別のものを参照しています（各オブジェクトは他と同じキーを使用しているため、マージできませんでした）。ただし、リスト内の各オブジェクトは{ "username": "foo", "id": 1 }ではなく[{ "username": "foo" }, { "id": 1 }]として格納されます。これは、1）短いため、2）ユーザー名とIDを持つものではなく、ユーザー名とIDを持つものを参照しているためです。 IDを持つもの。

2番目のオプションの問題は、JSONとしても、操作する際にも非常に冗長になることです。ただし、プロパティに関するメタ情報を格納する必要がある場合に使用できます。例：

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

ここでmutableは、親オブジェクトではなく、プロパティ自体を変更できるかどうかの架空のケースを指します。このようなメタ情報は、JavaScriptのObject.definePropertyに似ており、プロパティに関する「構成可能」、「列挙可能」、および「書き込み可能」情報を格納します。

5
gcampbell

Jsonを受け取る人の立場に身を置いてください。キー名がわからない場合、どのようにして最初または最後の形式でそれを取得するのですか？もちろん、jsonをループすることもできますが、3つの形式すべてが同じ結果を得るので、それは構文の問題です。これが唯一の意味のある質問だと思います。キー名がわかっている場合、最初または最後のオプションの方がコンパクトです。

3
JoulinRouge