Czy JSON powinien zawierać wartości null [zamknięte]

89

Tworzę API, które zwraca wyniki w formacie JSON. Czy istnieje obecnie najlepsza praktyka dotycząca tego, czy powinniśmy uwzględniać klucze w wyniku, gdy wartość jest równa 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 jest preferowany styl, czy nie. Z perspektywy klienta wydaje się, że oba style byłyby funkcjonalnie równoważne. Jakieś wady lub zalety każdego z nich?

— jjathman
źródło

6

Nie można odpowiedzieć poprawnie. Prawidłowa odpowiedź zależy od wymagań aplikacji. OP po prostu wybrał odpowiedź, która odpowiada jego wymaganiom. Jeśli Twoja aplikacja musi mieć możliwość rozróżnienia między wiedzą, czy „isbn” ma wartość null, a czy „isbn” nie zostało wysłane z serwera z innego powodu, musisz to uwzględnić.

— Jay

@Jacob Chociaż tego nie powiedziałem, moim zamiarem w przypadku tego pytania było zwrócenie „pełnego” kodu JSON reprezentującego odpowiedź. Kiedy klient może założyć, że wydaje się, że nie ma funkcjonalnej różnicy między tymi dwoma podejściami. Jeśli interfejs API wybiórczo nie zwraca kluczy / wartości, to tak, miałoby to duże znaczenie, jakie podejście zostało przyjęte.

— jjathman

zaletą pierwszej reprezentacji jest to, że schemat obiektu jest zachowany, a obecność właściwości nie jest niejednoznaczna na podstawie danych. w drugim formacie ta informacja zostaje utracona. Specyfikacja JSON jako taka nie narzuca formatu AFAIK

— Surya Pratap

32

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

Pod względem użyteczności nie sądzę, że ma to jakiekolwiek znaczenie. W obu przypadkach if(json.isbn)przejdzie do else. Zwykle nie ma potrzeby rozróżniania między null(brak wartości) i undefined(brak podanej wartości).

— Niet the Dark Absol
źródło

7

+1 for Zwykle nie ma potrzeby rozróżniania między null (brak wartości) a undefined (brak podanej wartości). Jest nawet do tego przydatny operator != null(nieprzeznaczony ściśle)

— Esailija

Jedynym przypadkiem, o jakim przychodzi mi do głowy, byłoby sprawdzenie, czy przeglądarka obsługuje określony typ zdarzenia. Na przykład, if( typeof onbeforepaste == "undefined")aby sprawdzić, czy onBeforePastejest obsługiwany. Nawet wtedy nie robi to żadnej różnicy, ponieważ możesz przypisać zdarzenia, ile chcesz (po prostu nic nie zrobią, jeśli nie są obsługiwane).

— Niet the Dark Absol

6

Jeśli chodzi o zapisywanie przesłanych bajtów, kompresja jest znacznie ważniejsza niż takie rzeczy, jak tablice indeksowane. web-resource-optimization.blogspot.no/2011/06/… Upewnij się, że to pierwsza rzecz, którą robisz. W większości przypadków dodawanie do tego takich rzeczy, jak tablice indeksowane, jest tym, co nazwałbym przedwczesną optymalizacją. Chyba że wysyłasz DUŻE ilości danych. Wymaga to również dodatkowego analizowania, co zwiększa złożoność aplikacji. Gzipowanie odbywa się bezproblemowo przez przeglądarkę. (zakładając, że klient jest przeglądarką)

— Martin Hansen

3

Ponieważ HTTPS staje się normą w dzisiejszych czasach (przynajmniej w przypadku aplikacji z dużą bazą użytkowników), kompresja idzie na marne. Zobacz en.wikipedia.org/wiki/CRIME_%28security_exploit%29

— Gaurav Vaish

6

Właściwie zrobiłbym -1 to dla „Zwykle nie ma potrzeby rozróżniania między wartością null”, gdybym miał reputację. Z 2 powodów: 1. powody do rozróżnienia istnieją i nie są rzadkie 2. najlepszą praktyką jest zawsze mieć wartości „dobrze zdefiniowane”, co oznacza, że zawsze należy unikać wszelkich niejasności - 2 znaczenia 1 wartości są zawsze złe - powinno być całkiem jasne.

— Srneczek

80

Jestem fanem zawsze włączania null wyraźnie, ponieważ ma to znaczenie. Pominięcie właściwości pozostawia niejednoznaczność.

Tak długo, jak Twój protokół z serwerem jest uzgodniony z dowolnym z powyższych, może działać, ale jeśli przekażesz wartości null z serwera, uważam, że dzięki temu twoje API będzie później bardziej elastyczne.

Powinienem również wspomnieć, że funkcja hasOwnProperty języka JavaScript zapewnia dalszy wgląd.

/* 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
źródło

3

Dokładnie, więcej osób musi zrozumieć różnicę między wartością „”, wartością null i undefined. Odpowiedź na to pytanie zależy od wymagań użytkowników.

— Jay

13

+1. Osobie po drugiej stronie (która napisała kod) będą lepiej służyć wyraźne wartości. Mogą nie pisać JavaScript ;-)

— Steve11235

2

Zwróć uwagę, że sprawdzanie wartości null nie działa z ==, === jest wymagane (ponieważ undefined == null)!

— Tommy

dokładnie pierwsza część zaakceptowanej odpowiedzi jest tak błędna ...

— Srneczek

"propertyName" in objectFromJSONZamiast tego napisałbym objectFromJSON.hasOwnProperty("propertyName"). Ponadto, jeśli nalegasz na używanie, hasOwnPropertynapisz Object.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")dla bezpieczeństwa.

— Aadit M Shah

22

W JavaScript nulloznacza coś zupełnie innego niż undefined.

Dane wyjściowe JSON powinny odzwierciedlać to, co jest używane i potrzebne w aplikacji w określonym kontekście korzystania z danych JSON.

— Ćwiek
źródło

5

W JSON nie ma „undefined”, więc myślę, że pyta tylko, czy uwzględnić „puste” właściwości, czy nie - {"prop":undefined}różni się od {}.

— Bergi

Zgoda, próbuję wyjaśnić, że po stronie odbiorczej, jeśli szuka on konkretnej właściwości, która ma być ustawiona na zero, to nie będzie. Jeśli zostanie pominięty, będzie niezdefiniowany.

— Brad,

11

Zdecydowanie powinieneś to uwzględnić, jeśli istnieje potrzeba rozróżnienia między nimi, nulla undefinedponieważ mają one dwa różne znaczenia w JavaScript. Możesz myśleć o nullznaczeniu, że właściwość jest nieznana lub pozbawiona znaczenia, i undefinedże oznacza, że właściwość nie istnieje.

Z drugiej strony, jeśli nie ma potrzeby, aby ktokolwiek dokonywał takiego rozróżnienia, nie przejmuj się.

— Paweł
źródło

0

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

Różnica pojawia się w plikach JSON-config, gdy użytkownik powinien coś edytować ręcznie. Korzystając z pierwszego przykładu, dajesz użytkownikowi wskazówkę dotyczącą konfiguracji.

— Alexey Kachalov
źródło

1

Czy mógłbyś bardziej szczegółowo opisać swoją odpowiedź, dodając więcej opisu rozwiązania, które oferujesz?

— abarisone