JSON dovrebbe includere valori nulli [chiuso]

89

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

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

o

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

Poiché il secondo è più piccolo, mi sto avvicinando a questo stile, ma non sono sicuro se esista uno stile preferito o meno. Dal punto di vista del cliente, sembra che entrambi gli stili sarebbero funzionalmente equivalenti. Qualche pro o contro per ciascuno?

— jjathman
fonte

6

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

— Jay,

@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ò presumere che non sembra esserci alcuna differenza funzionale tra i due approcci. Se l'API non restituisse selettivamente chiavi / valori, sì, farebbe una grande differenza quale approccio è stato adottato.

— jjathman

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

— Surya Pratap

32

Il secondo risparmierà una piccola quantità sulla larghezza di banda, ma se questo fosse un problema, useresti anche array indicizzati invece di riempire il JSON con le chiavi. Chiaramente, ["Foo Bar","Joe Blow"]è molto più breve di quello che hai ora.

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

— Niet the Dark Absol
fonte

7

+1 per Di solito non è necessario distinguere tra null (nessun valore) e undefined (nessun valore dato). C'è anche un pratico operatore per questo != null(inteso non rigoroso)

— Esailija

L'unico caso a cui riesco a pensare sarebbe testare se un browser supporta un certo tipo di evento. Ad esempio, if( typeof onbeforepaste == "undefined")per vedere se onBeforePasteè supportato. Anche in questo caso non fa alcuna differenza poiché puoi assegnare gli eventi tutto ciò che desideri (semplicemente non faranno nulla se non sono supportati).

— Niet the Dark Absol

6

In termini di salvataggio dei byte trasferiti, la compressione è molto più importante di cose come gli array indicizzati. web-resource-optimization.blogspot.no/2011/06/… Assicurati che sia la prima cosa che fai. Nella maggior parte dei casi l'aggiunta di cose come array indicizzati sopra è ciò che chiamerei ottimizzazione prematura. A meno che tu non invii GRANDI quantità di dati. Ciò richiede anche un'analisi aggiuntiva, aggiungendo più complessità alla tua app. Gzipping viene eseguito senza problemi dal browser. (supponendo che il client sia un browser)

— Martin Hansen

3

Con HTTPS che diventa la norma del giorno (almeno per le app con una vasta base di utenti), la compressione è un problema. Vedi en.wikipedia.org/wiki/CRIME_%28security_exploit%29

— Gaurav Vaish,

6

In realtà vorrei -1 questo per "Di solito non c'è bisogno di distinguere tra null" se avessi reputazione. Da 2 motivi: 1. i motivi per distinguere esistono e non sono rari 2. la migliore pratica è avere sempre valori "ben definiti", il che significa evitare sempre qualsiasi ambiguità - 2 significati di 1 valore è sempre cattivo - dovrebbe essere abbastanza chiaro ..

— Srneczek

80

Sono un fan di includere sempre null in modo esplicito poiché ciò ha un significato. L'omissione di una proprietà lascia ambiguità.

Finché il tuo protocollo con il server è concordato, uno qualsiasi dei precedenti può funzionare, ma se passi valori nulli dal server credo che ciò renda le tue API più flessibili in seguito.

Dovrebbe anche menzionare che la funzione hasOwnProperty di javascript ti 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 )

— rushkeldon
fonte

3

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

— Jay il

13

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

— Steve11235

2

Nota che il controllo con null non funziona con ==, === è richiesto (perché undefined == null)!

— Tommy

esattamente la prima parte della risposta accettata è così sbagliata ...

— Srneczek

Scriverei "propertyName" in objectFromJSONinvece di objectFromJSON.hasOwnProperty("propertyName"). Inoltre, se insisti nell'usare, hasOwnPropertyscrivi Object.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")per sicurezza.

— Aadit M Shah

22

In JavaScript, nullsignifica qualcosa di molto diverso da undefined.

L'output JSON dovrebbe riflettere ciò che viene utilizzato e necessario dalla tua applicazione nel contesto specifico di utilizzo dei dati JSON.

— Brad
fonte

5

Non esiste "undefined" in JSON, quindi penso che chieda solo se includere proprietà "vuote" o meno - {"prop":undefined}è diverso da {}.

— Bergi

D'accordo, sto cercando di spiegare che al destinatario, se sta cercando una proprietà specifica da impostare su null, non lo sarà. Non sarà definito, se tralasciato.

— Brad il

11

Dovresti assolutamente includerlo se è necessario distinguere tra nulle undefinedpoiché hanno due significati diversi in Javascript. Puoi pensare nullche significhi che la proprietà è sconosciuta o priva di significato e undefinedche significa che la proprietà non esiste.

D'altra parte, se non c'è bisogno che nessuno faccia questa distinzione, allora vai avanti e lasciala fuori.

— Paolo
fonte

0

Penso che non faccia differenza quando usi 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 usi il primo esempio, dai all'utente qualche suggerimento sulla configurazione.

— Alexey Kachalov
fonte

1

Potresti elaborare maggiormente la tua risposta aggiungendo un po 'più di descrizione sulla soluzione fornita?

— abarisone