2012-06-12 16 views
83

Sto creando un'API che restituisce risultati come JSON. Esiste una best practice corrente per stabilire se dovremmo includere le chiavi nel risultato quando il valore è nullo? Per esempio:JSON dovrebbe includere valori nulli

{ 
    "title":"Foo Bar", 
    "author":"Joe Blow", 
    "isbn":null 
} 

o

{ 
    "title":"Foo Bar", 
    "author":"Joe Blow" 
} 

Dal momento che la seconda è più piccola che sto appoggiato verso questo stile, ma non sono sicuro se c'è uno stile preferito o no. Dal punto di vista del cliente, sembra che entrambi gli stili siano funzionalmente equivalenti. Qualsiasi pro o contro a ciascuno?

+5

È impossibile rispondere correttamente. La risposta corretta dipende dai requisiti dell'applicazione. L'OP ha semplicemente selezionato la risposta più adatta alle sue esigenze. Se la tua applicazione deve essere in grado di distinguere tra sapere se "isbn" è nullo o se "isbn" potrebbe non essere stato inviato dal server per un altro motivo, devi includerlo. – Jacob

+0

@Jacob Anche se non l'ho detto, la mia intenzione con questa domanda era che il JSON "completo" che rappresenta la risposta fosse restituito. Quando un cliente può assumere che non sembra esserci alcuna differenza funzionale tra i due approcci.Se l'API non restituisse in modo selettivo le chiavi/i valori allora sì, farebbe una grande differenza quale approccio è stato preso. – jjathman

+0

il vantaggio della prima rappresentazione è che lo schema dell'oggetto è preservato, la presenza della proprietà non è ambigua in base ai dati. nel secondo formato questa informazione è persa. La specifica JSON in quanto tale non richiede alcun formato AFAIK –

risposta

30

Il secondo consente di risparmiare una piccola quantità sulla larghezza di banda, ma se ciò fosse un problema, utilizzare anche le matrici indicizzate anziché riempire il JSON con le chiavi. Chiaramente, ["Foo Bar","Joe Blow"] è molto più breve di quello che hai ora.

In termini di usabilità, non penso che faccia alcuna differenza. In entrambi i casi, if(json.isbn) salterà allo else. Di solito non è necessario distinguere tra null (nessun valore) e undefined (nessun valore dato).

+7

+1 per * Di solito non c'è bisogno di distinguere tra null (nessun valore) e indefinito (nessun valore dato). * C'è anche un operatore pratico per esso '! = Null' (non intenzionale) – Esailija

+0

L'unico caso Posso pensare di testare se un browser supporta un determinato tipo di evento. Ad esempio, 'if (typeof onbeforepaste ==" undefined ")' per vedere se 'onBeforePaste' è supportato. Anche in questo caso non fa alcuna differenza dal momento che puoi assegnare gli eventi desiderati (semplicemente non faranno nulla se non sono supportati). –

+0

In tal caso, testerei "onbeforepaste" nel documento', per verificare l'esistenza della proprietà. – Esailija

19

In JavaScript, null significa qualcosa di molto diverso da undefined.

L'output JSON deve riflettere ciò che viene utilizzato e richiesto dall'applicazione nel contesto specifico dell'utilizzo dei dati JSON.

+4

Non c'è alcun "non definito" in JSON, quindi penso che chiede solo se includere proprietà "vuote" oppure no - '{" prop ": undefined}' è diverso da '{ } '. – Bergi

+0

D'accordo, sto cercando di spiegare che dal lato ricevente, se sta cercando una proprietà specifica da impostare su null, non lo sarà. Sarà indefinito, se lasciato fuori. – Brad

10

Si consiglia di includerlo se è necessario distinguere tra null e undefined poiché questi hanno due significati diversi in Javascript. Puoi pensare a null nel senso che la proprietà è sconosciuta o priva di significato, e undefined nel senso che la proprietà non esiste.

D'altra parte, se non è necessario per nessuno fare questa distinzione, andare avanti e lasciarlo fuori.

71

Sono un fan di sempre includendo null esplicitamente come che porta significato. Mentre omettere una proprietà lascia ambiguità.

Fintantoché il protocollo con il server è concordato su uno dei precedenti, può funzionare, ma se si superano i valori nulli dal server, credo che le API diventino più flessibili in seguito.

Dovrebbe anche menzionare che la funzione hasOwnProperty di javascript offre ulteriori informazioni.

/* if true object DOES contain the property with *some* value */ 
if(objectFromJSON.hasOwnProperty("propertyName")) 

/* if true object DOES contain the property and it has been set to null */ 
if(jsonObject.propertyName === null) 

/* if true object either DOES NOT contain the property 
    OR 
    object DOES contain the property and it has been set to undefined */ 
if(jsonObject.propertyName === undefined) 
+3

Esattamente, più persone hanno bisogno di capire la differenza tra "", null e undefined. La risposta a questa domanda dipende dai requisiti degli utenti. – Jacob

+11

+1. La persona dall'altra parte (chi ha scritto il codice) sarà meglio servita da valori espliciti. Potrebbero non scrivere JavaScript ;-) – Steve11235

+2

Nota che il controllo rispetto a null non funziona con ==, è richiesto === (perché non definito == null)! – Tommy

0

Penso che non faccia alcuna differenza quando si utilizza il JSON come dati dietro l'esperienza dell'utente.

La differenza appare nei file di configurazione JSON, quando un utente deve modificare qualcosa a mano. Quando si utilizza il primo esempio, si fornisce all'utente qualche suggerimento sulla configurazione.

+1

Potresti per favore elaborare più la tua risposta aggiungendo un po 'più di descrizione della soluzione che fornisci? – abarisone