Czy JSON powinien zawierać wartości null

Tworzę API, które zwraca wyniki jako JSON. Czy istnieje Aktualna najlepsza praktyka dotycząca tego, czy powinniśmy uwzględniać klucze w wyniku, gdy wartość jest null? Na przykład: 

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

Lub 

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

Ponieważ drugi jest mniejszy, skłaniam się ku temu stylowi, ale nie jestem pewien, czy istnieje preferowany styl, czy nie. Z perspektywy klienta wydaje się, że oba style byłyby funkcjonalnie równoważne. Jakieś plusy lub minusy dla każdego?

Author: Paulpro, 2012-06-12
Source

5 answers

Drugi pozwoli zaoszczędzić niewielką ilość przepustowości, ale gdyby to było problemem, użyłbyś również indeksowanych tablic zamiast wypełniać JSON kluczami. Najwyraźniej ["Foo Bar","Joe Blow"] jest znacznie krótszy niż to, co masz teraz.

Jeśli chodzi o użyteczność, nie sądzę, aby to miało jakąkolwiek różnicę. W obu przypadkach if(json.isbn) przejdzie do else. Zazwyczaj nie ma potrzeby rozróżniania pomiędzy null (bez wartości) i undefined (bez podanej wartości).

 29
Author: Niet the Dark Absol,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-12 19:27:39

Jestem fanem always including null explicite, ponieważ ma to znaczenie. Pominięcie właściwości pozostawia niejasność.

Tak długo, jak Twój protokół z serwerem jest uzgodniony, każdy z powyższych może działać, ale jeśli przekażesz null z serwera, wierzę, że to uczyni Twoje API bardziej elastycznymi później.

Należy również wspomnieć, że funkcja hasOwnProperty javascript daje Ci więcej wglądu.

/* 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 )
 72
Author: rushkeldon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-09 06:34:23

W JavaScript, null oznacza coś zupełnie innego niż undefined.

Wyjście JSON powinno odzwierciedlać to, co jest używane i potrzebne przez aplikację w konkretnym kontekście korzystania z danych JSON.

 20
Author: Brad,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-12 19:25:23

Zdecydowanie powinieneś to uwzględnić, jeśli istnieje potrzeba rozróżnienia między null i undefined, ponieważ mają one dwa różne znaczenia w Javascript. Możesz myśleć o null jako o tym, że właściwość jest nieznana lub bez znaczenia, a undefined jako o tym, że właściwość nie istnieje.

Z drugiej strony, jeśli nie ma potrzeby, aby ktokolwiek dokonał tego rozróżnienia, to śmiało i go pominąć.

 10
Author: Paulpro,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-12 19:25:53

Myślę, że nie ma różnicy, kiedy używasz JSON jako danych za doświadczeniem użytkownika.

Różnica pojawia się w plikach JSON-config, gdy użytkownik powinien edytować coś ręcznie. Kiedy użyjesz pierwszego przykładu, podasz użytkownikowi podpowiedź o konfiguracji.

 0
Author: Alexey Kachalov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-18 07:51:01