階層データ用のフラットまたはネストされたJSON？

既に5回前後に切り替えました。このRESTエンドポイントは/api/tags/内部で使用するものであり（サードパーティのクライアントはありません）、私がそれを使用しているのは私だけです。

私はこれらの2つの表現の間で決定しています：

平らな

{  
   "types":[  
      {  
         "id":1,
         "text":"Utility"
      },
      {  
         "id":7,
         "text":"Lease Terms"
      },
   ],
   "tags":[
      {  
         "id":8,
         "text":"Water",
         "type":1
      },
      {  
         "id":9,
         "text":"Electricity",
         "type":1
      },
      {  
         "id":5,
         "text":"Minimum 12 month lease",
         "type":7
      },
      {  
         "id":17,
         "text":"lease negotiable/flexible",
         "type":7
      },
   ]
}

• ややモジュール化されています。互換性を損なうことなく、「国」などの別の最上位レイヤーを追加できます。

入れ子

{  
   "1":{  
      "text":"Utility",
      "tags":{  
         "8":{  
            "text":"Water"
         },
         "9":{  
            "text":"Electricity"
         },
      }
   },
   "2":{  
      "text":"Lease Terms",
      "tags":{  
         "5":{  
            "text":"Minimum 12 month lease"
         },
         "17":{  
            "text":"lease negotiable/flexible"
         },
      }
   },
}

• すでに使用可能な形式になっています。データを使用する前にループする必要はありません。
• 帯域幅を節約します。gzipの後でも、これはわずかに小さくなります。

どちらを使用する必要があり、なぜですか？これが個人的な好みの問題である場合、経験豊富な開発者はどの表現を好むでしょうか？その理由は？

ユースケースに依存します。

statica型付き言語でJSONを使用する場合、構造が型にマップされると大きなボーナスがあります。つまり、キーの名前はすべて事前に知っておく必要があります。

したがって、Javaを使用してサービスを使用する予定がある場合、またはJSONスキーマを使用してドキュメント化する予定の場合は、1つ目の方がはるかにクリーンになります（もちろん両方とも機能します）。

これ以上の文脈なしで言うのは難しい。私は両方で仕事をしましたが、次第に1番に傾倒し始めました。一般的に、単純さは洗練よりも重要であることがわかりました。

＃1では、エンティティと関係は明確で明白ですが、＃2では異なる考え方が必要です。一部の人々にとって、ツリーは（データ構造として）自己記述的ではありません。Person> Addressよりも深い構図|集合を見ているジュニア開発者を考えてください。

＃1は次のように読むことができます。

• 型付きタグのコレクションがあります。

しかし、どうすれば7語で＃2を説明できますか？ツリー構造に慣れていない場合は、＃2を次のように読むことができます。

• タグには5と17の2つの属性がありますが、それらのタイプはわかりません。タイプが何であれ、1つの属性textがあります。

誤解しないでください。＃2はスマートなソリューションかもしれませんが、不必要に賢さ（または効率）のために読みやすさを犠牲にすることはありません。

この回答を書いている時点で、私はサードパーティサービスと統合する必要があるプロジェクトに取り組んでいます。このサービスは＃2と非常によく似ています。このサービスは、年、月、日、時間のカレンダーを提供しています

 { "2017" : { "01": { "01" : ["00:00", "01:00", "02:00"] } } } 

Java開発者として、サービスレスポンスのデシリアライゼーションは、ゲッター|セッター|コンストラクターを介したクラスへの直接マッピングがないため、読み取り可能なコードで終わりました。代わりに、ドキュメント（getNode、getSiblings、getNodeName、getChildAsText、isNodeObject、isTextなど）を走査し、クラスの階層を手動で作成する必要がありました。最後に、数字のツリーをタイムスタンプのコレクションにマッピングすることに成功しました！どの構造が読みやすく、逆シリアル化が簡単だと思いますか？そして、あなたがクライアント側にいたら、どれを手に入れたいですか？

他に何も必要ない場合は、次を使用できます。

{
    "Utility": {
        "8": "Water",
        "9": "Electricity"
     },
     "Lease Terms": {
        "5": "Minimum 12 month lease",
        "17": "lease negotiable/flexible"
     }
}

ここで残念なことに、JSONはキーとして文字列のみを許可します。