2010-01-21 16 views
6

Ho il compito di definire la comunicazione tra due applicazioni web. Ho deciso di usare JSON per questo. Quanto è comune avere un nodo radice nel JSON?Nodi di radice in JSON

Diciamo che abbiamo un oggetto auto. Questo è il JSON con "Auto" è il nodo principale:

{"Car": { 
    "Make":"Mustang", 
    "YearBuilt":"1999"}} 

Così ora diciamo che avere un oggetto Tiro e dal momento che stiamo standardizzando per aver nodi principali, questo ha anche di averlo.

{"Tire": {"Make": "Brirdgestone", "Size":"15"}} 

L'integrazione dell'oggetto pneumatico JSON nell'oggetto Car originale mostra quanto potrebbe essere ingombrante.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999", 
"Tires": "[{"Tire": {"Make": "Brirdgestone", "Size":"15"}}, 
{"Tire": {"Make": "Brirdgestone", "Size":"15"}}, 
{"Tire": {"Make": "Bridgestone", "Size":"15"}}, 
{"Tire": {"Make": "Brirdgestone", "Size":"15"}} 
]}} 

Così serializzato in PHP, la marca del primo pneumatico sarebbe $object->Car->Tires[0]->Tire->Make. C'è quel livello di Tyre extra lì a causa del nodo root.

Se Tiro non ha il nodo radice, il codice potrebbe essere molto più sottile.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999", 
"Tires": "[{ {"Make": "Bridgestone", "Size":"15"}}, 
{"Make": "Brirdgestone", "Size":"15"}}, 
{"Make": "Brirdgestone", "Size":"15"}}, 
{"Make": "Brirdgestone", "Size":"15"}}]}} 

In PHP, c'è meno confusione perché c'è meno la ridondanza: La marca del primo pneumatico viene chiamato da $object->Car->Tires[0]->Make

C'è qualcosa di male da non avere un nodo principale? Mi piace avere il root node perché agisce come un nome di classe, ma i livelli inutili mi infastidiscono molto e renderanno il percorso più complesso.

risposta

4

mi piacerebbe omettere entrambi i nodi principali, pneumatici e Car.

Ricordare che l'uso principale di JSON è il trasferimento di oggetti sulla rete in un formato compatto. Non c'è un vero altro uso oltre a questo. Si desidera lavorare con i dati che codifica JSON e aggiungendo i nodi radice, si creano oggetti contenitore vuoti senza identità e scopo reali. Quando Omissione i nodi principali, si ottiene

$car->tires[0]->make 

ed in JS si otterrebbe

car.tires[0].make 

Questo è molto più chiara e rappresenta l'oggetto molto meglio. Ricorda, questo è ciò con cui dovrai lavorare. Certo, potresti usare una sorta di mapper JSON che mappa come gli oggetti dovrebbero essere serializzati e che hanno come risultato gli oggetti sopra, ma questo è un grande sforzo in più e non ne vale la pena.

Se si desidera avere il nome classe nel JSON, è sufficiente impostarlo come proprietà, ad es.

{ 'klass': 'Car', 'make': 'Mustang', 'year':1999 } 
+0

Sono d'accordo. I nodi radice renderebbero inutilmente prolisso il codice dell'app che consuma. – Steve

+0

Cool, grazie mille. Ho pensato a un'area in cui sarebbe importante. Se i mirror JSON e il documento XML, dovresti aggiungerne uno almeno sull'oggetto principale perché in XML hai bisogno di un elemento root. Un collega ha anche sottolineato che è importante per i callback JSONP e sarebbe una struttura migliore se stavo creando un'API. Ad esempio, le API di Yahoo e ebay avvolgono tutto attorno a un nodo ResultSet. Ciò consente ai parser che si preoccupano dei tipi di associare il ResultSet a un tipo di oggetto. –

+0

Beh, sono sicuro che puoi pensare a UseCases in cui potrebbe tornare utile, ma poi, ogni volta che ho usato JSON nelle mie app, ho ricevuto dei callback che sapevano come gestire i dati ricevuti, ad es. example.com/cars/find/id/123 restituirebbe i dati dell'auto e la mia callback li creerebbe. – Gordon

0

@Gordon ha buoni punti. Tuttavia, mi piace utilizzare AOP con i messaggi AJAX per intercettare i messaggi da e verso il server. Questi intercettatori aggiungono a ciascun messaggio un timestamp e sui messaggi inviati dal server un flag di stato (fail, eccezione, successo, qualunque cosa ...). Come probabilmente hai ipotizzato, ho usato un nodo JSON di root per payload, status e timestamp.

Il flag di stato inviato dal server può essere esaminato in una funzione (aspetto) sul front-end e tutte le eccezioni gestite in un'unica posizione. Quando il server non riesce per un motivo diverso da un'eccezione, l'aspetto/avviso consente di trasmettere i dati all'iniziatore AJAX.

Problemi correlati