Flaches oder verschachteltes JSON für hierarchische Daten?

Ich habe schon ~ 5 mal hin und her geschaltet. Dieser REST-Endpunkt bei/api/tags/ ist für den internen Gebrauch bestimmt (keine Clients von Drittanbietern). Ich bin der einzige, der damit arbeitet.

Ich entscheide mich zwischen diesen beiden Darstellungen:

Eben

{  
   "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
      },
   ]
}

• Es ist etwas modular. Kann eine weitere oberste Ebene wie "country" hinzufügen, ohne die Kompatibilität zu beeinträchtigen.

Verschachtelt

{  
   "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"
         },
      }
   },
}

• Es ist bereits in einem verwendbaren Format. Sie müssen keine Daten durchlaufen, bevor Sie sie verwenden.
• Spart etwas Bandbreite. Auch nach gzip ist dies etwas kleiner.

Welches sollte verwendet werden und warum? Wenn dies eine Frage der persönlichen Präferenz ist, welche Vertretung würden erfahrene Entwickler bevorzugen und warum?

Hängt von Ihrem Anwendungsfall ab.

Wenn Sie JSON mit statisch typisierten Sprachen verwenden, gibt es einen großen Vorteil, wenn Ihre Struktur Ihren Typen zugeordnet wird. Dies bedeutet, dass alle Namen der Schlüssel im Voraus bekannt sein sollten.

Wenn Sie also vorhaben, den Service mit Java zu nutzen oder ihn mit JSON Schema zu dokumentieren, wird Nummer eins viel sauberer (natürlich funktionieren beide).

Schwer zu sagen ohne mehr Kontext. Ich habe mit beiden gearbeitet, aber nach und nach begann ich mich auf # 1 zu lehnen. Im Allgemeinen habe ich Einfachheit als relevanter als Raffinesse empfunden.

In # 1 sind Entitäten und Beziehungen klar und offensichtlich, während # 2 eine andere Denkweise erfordert. Für manche Menschen sind Bäume (als Datenstrukturen) nicht so selbstbeschreibend. Denken Sie an Nachwuchsentwickler, die kaum eine tiefere Zusammenstellung als Person> Adresse gesehen haben .

Ich könnte # 1 lesen als:

• Es gibt eine Sammlung von typisierten Tags .

Aber wie könnten wir # 2 nur in 7 Worten beschreiben? Wenn ich mit Baumstrukturen nicht vertraut wäre, könnte ich # 2 als lesen

• Tags haben zwei Attribute 5 und 17, aber ich kenne ihre Typen nicht. Was auch immer der Typ ist, hat ein Attribut, Text .

Versteh mich nicht falsch, # 2 könnte eine clevere Lösung sein, aber ich würde die Lesbarkeit nicht unnötig für die Klugheit (oder Effizienz) opfern.

Beim Schreiben dieser Antwort arbeite ich an einem Projekt, das in einen Drittanbieter integriert werden muss, dessen Antworten denen von Nummer 2 sehr ähnlich sind. Der Service stellt uns einen Kalender zur Verfügung: Jahr, Monate, Tage und Stunden des Tages

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

Als Java-Entwickler habe ich festgestellt, dass die Deserialisierung der Serviceantwort alles andere als lesbar ist, da Klassen nicht direkt durch Getters | Setters | -Konstruktoren zugeordnet werden können. Stattdessen musste ich das Dokument durchlaufen ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText usw.) und meine Klassenhierarchie manuell auffüllen . Schließlich habe ich es geschafft, den Zahlenbaum einer Sammlung von Zeitstempeln zuzuordnen! Welche Struktur ist Ihrer Meinung nach leichter zu lesen und zu deserialisieren? Und welches würdest du gerne bekommen, wenn du auf der Kundenseite wärst?

Wenn Sie nichts anderes wollten, können Sie einfach Folgendes verwenden:

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

Leider erlaubt JSON nur Strings als Schlüssel.