JSON piatto o annidato per i dati gerarchici?

Question

JSON piatto o annidato per i dati gerarchici?

#1 da (5 voti)
#2 da (2 voti)
#3 da (0 voti)

7

Sono passato avanti e indietro ~ 5 volte già. Questo endpoint REST in /api/tags/ sarà per uso interno (nessun client di terze parti), io sono l'unico che lavora con esso.

Sto decidendo tra queste due rappresentazioni:

piano

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

È un po 'modulare. È possibile aggiungere un altro strato superiore come "Paese" senza compromettere la compatibilità.

nidificati

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

È già in un formato utilizzabile. Non è necessario eseguire il loop dei dati prima di utilizzarli.
Salva un po 'di larghezza di banda. Anche dopo gzip, questo è leggermente più piccolo.

Quale dovrebbe essere usato e perché? Se si tratta di preferenze personali, quale rappresentazione avrebbe preferito gli sviluppatori e perché?

api-design rest json

posta dtgq 10.06.2017 - 22:59

fonte

3 risposte

Leggi altre domande sui tag api-design rest json

Dovrebbe essere definito ogni metodo in una classe in un'interfaccia implementata? Composizione di due classi con radice ereditaria comune

score 5 · Answer 1

Dipende dal tuo caso d'uso.

Quando usi JSON con una lingua tipizzata in modo statico, c'è un enorme bonus se la tua struttura si adatta ai tuoi tipi. Ciò significa che tutti i nomi delle chiavi dovrebbero essere conosciuti in anticipo.

Quindi, se prevedi di utilizzare Java per consumare il servizio, o se prevedi di documentarlo con JSON Schema, il numero uno sarà molto più pulito (ovviamente funzioneranno entrambi).

score 2 · Answer 2

Difficile da dire senza un contesto sufficiente. Ho lavorato con entrambi i formati, ma tendo a strutturare i dati come opzione n. 1. In generale, preferisco la semplicità alla sofisticazione. Mentre # 2 potrebbe essere sinonimo di efficienza, il primo è sinonimo di leggibilità che penso sia spesso una caratteristica più rilevante.

Le strutture dati e la relazione tra di esse sono evidenti nell'opzione n. 1, mentre la seconda implica un diverso modo di pensare. Per alcune persone, le strutture ad albero non sono auto-descrittive in modo così esplicito. Pensa agli sviluppatori junior che hanno appena visto una composizione / aggregazione più profonda di Person > Indirizzo .

Essendo semplicistico, ho potuto leggere il primo approccio come:

c'è una raccolta di tag digitati

Ma come descrivere il secondo approccio in sole 6 parole? Immagino sia possibile, ma a prima vista non è così ovvio.

Esempio:

"tags":{ "5":{ "text":"Minimum 12 month lease" }, "17":{ "text":"lease negotiable/flexible" }

Se non avessi familiarità con JSON e strutture ad albero, potrei leggere la struttura come:

i tag di entità hanno due attributi: 5 e 17 ma non conosco il tipo. Qualunque sia il tipo, ha solo un attributo: text

Non fraintendermi, la seconda opzione potrebbe essere una soluzione più intelligente, ma non sacrificherei la leggibilità con intelligenza o raffinatezza.

Qui usiamo l'espressione "Idea felice". Un'idea felice potrebbe avere senso per me e non renderla per gli altri, o essere difficile da spiegare.

Come ho detto, ho lavorato con entrambi gli approcci. Lo faccio davvero. Nel mio progetto attuale, devo integrare il back-end con un servizio web di terze parti, le cui risposte sono molto simili all'opzione # 2. Come sviluppatore Java, sono d'accordo con @fdreger. La deserializzazione della risposta al servizio web è tutt'altro che leggibile perché non esiste una mappatura diretta su getter / setter e classi. Ho dovuto eseguire il loop sulla struttura utilizzando l'API del mapper: getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, ecc ... . Il servizio web ci fornisce un calendario: anno, mesi, giorni, ore del giorno, ecc. Potrei gestirlo per trasformare il loro albero in una collezione di timestamp !!! Quale pensi sia più facile da mappare e con cui lavorare?

Per una lingua come Javascript, la mappatura è trasparente e diretta. Mi chiedo se sia anche per Python. So che OOP è opzionale in Python e forse rende il linguaggio molto meno tipizzato e flessibile, come Javascript.

Tuttavia, la progettazione di una struttura dati oltre le funzionalità del linguaggio è un modo un po 'per esporre i dettagli dell'implementazione e condizionare l'integrazione nelle lingue con queste specifiche capacità.

score 0 · Answer 3

Se non volevi altro, puoi semplicemente usare:

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

Sfortunatamente qui JSON consente solo le stringhe come chiavi.