J'ai déjà fait des allers-retours ~ 5 fois. Ce REST point final à /api/tags/
sera à usage interne (pas de clients tiers), je suis le seul à travailler avec.
Je décide entre ces deux représentations:
plat
{
"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
},
]
}
imbriqué
{
"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"
},
}
},
}
Lequel devrait être utilisé et pourquoi? S'il s'agit d'une préférence personnelle, quelle représentation les développeurs expérimentés préféreraient-ils et pourquoi?
Cela dépend de votre cas d'utilisation.
Lorsque vous utilisez JSON avec des langages typés statica, il y a un énorme bonus si votre structure correspond à vos types. Cela signifie que tous les noms des clés doivent être connus à l'avance.
Donc, si vous prévoyez d'utiliser Java pour consommer le service, ou si vous prévoyez de le documenter avec le schéma JSON, le numéro un sera beaucoup plus propre (bien sûr, les deux fonctionneront).
Difficile à dire sans plus de contexte. J'ai travaillé avec les deux mais progressivement j'ai commencé à m'appuyer sur le n ° 1. En général, j'ai trouvé la simplicité plus pertinente que la sophistication.
Dans # 1, les entités et les relations sont claires et évidentes, tandis que # 2 nécessite une manière différente de penser. Pour certaines personnes, les arbres (en tant que structures de données) ne sont pas auto-descriptifs. Pensez aux développeurs juniors qui ont à peine vu une composition | agrégation plus profonde que Personne> Adresse.
Je pourrais lire # 1 comme:
Mais, comment pourrions-nous décrire # 2 seulement en 7 mots? Si je ne connaissais pas les structures arborescentes, je pourrais lire # 2 comme
Ne vous méprenez pas, # 2 pourrait être une solution intelligente, mais je ne sacrifierais pas inutilement la lisibilité pour l'intelligence (ou l'efficacité).
Au moment de la rédaction de cette réponse, je travaille sur un projet qui doit être intégré à un service tiers dont les réponses sont très similaires à # 2. Le service nous fournit un calendrier: année, mois, jours et heures de la journée
{ "2017" : { "01": { "01" : ["00:00", "01:00", "02:00"] } } }
En tant que Java que je suis, la désérialisation de la réponse du service s'est terminée par un code qui est tout sauf lisible car il n'y a pas de mappage direct vers les classes via les constructeurs getters | setters |. Au lieu de cela, j'ai dû parcourir le document (getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, etc) et remplir ma hiérarchie de classes manuellement. Enfin, j'ai réussi à mapper l'arbre des nombres dans une collection d'horodatages! diriez-vous que la structure est plus facile à lire et à désérialiser? Et laquelle aimeriez-vous obtenir si vous étiez du côté client?
Si vous ne vouliez rien d'autre, vous pouvez simplement utiliser:
{
"Utility": {
"8": "Water",
"9": "Electricity"
},
"Lease Terms": {
"5": "Minimum 12 month lease",
"17": "lease negotiable/flexible"
}
}
Malheureusement, JSON n'autorise que les chaînes comme clés.