2012-06-12 17 views
83

Tworzę interfejs API, który zwraca wyniki jako JSON. Czy istnieje aktualna najlepsza praktyka, czy powinniśmy uwzględniać klucze w wyniku, gdy wartość jest zerowa? Na przykład:Jeśli JSON ma wartości puste

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

lub

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

Ponieważ druga jest mniejsza mam skłonność do tego stylu, ale nie jestem pewien, czy nie jest preferowany styl czy nie. Z perspektywy klienta wydaje się, że oba style będą funkcjonalnie równoważne. Jakieś plusy i minusy dla każdego?

+5

Nie można poprawnie odpowiedzieć. Prawidłowa odpowiedź zależy od wymagań aplikacji. PO po prostu wybrał odpowiedź, która odpowiada jego wymaganiom. Jeśli twoja aplikacja musi być w stanie odróżnić, czy "isbn" ma wartość null, a "isbn" nie został wysłany z serwera z innego powodu, musisz go uwzględnić. – Jacob

+0

@Jacob Chociaż nie powiedziałem tego, moim zamiarem z tym pytaniem było to, że "pełny" JSON reprezentujący odpowiedź został zwrócony. Kiedy klient może założyć, że nie ma żadnej funkcjonalnej różnicy między tymi dwoma podejściami.Gdyby API wybiórczo nie zwracał kluczy/wartości, to tak, miałoby duże znaczenie, jakie podejście zostało podjęte. – jjathman

+0

Zaletą pierwszego przedstawienia jest zachowanie schematu obiektu, obecność właściwości nie jest niejednoznaczna na podstawie danych. w drugim formacie informacja ta jest tracona. Specyfikacja JSON jako taka nie wymaga ani formatu AFAIK –

Odpowiedz

30

Drugi zaoszczędzi niewielką ilość na przepustowości, ale gdyby to było problemem, używałbyś też tablic indeksowanych zamiast wypełniania JSON-ami kluczami. Oczywiście, ["Foo Bar","Joe Blow"] jest znacznie krótszy niż to, co masz teraz.

Pod względem użyteczności, nie sądzę, żeby to miało jakikolwiek wpływ. W obu przypadkach if(json.isbn) przejdzie do else. Zwykle nie ma potrzeby rozróżniania między wartościami: null (brak wartości) i undefined (bez podanej wartości).

+7

+1 dla * Zazwyczaj nie ma potrzeby rozróżniania między wartością zerową (brak wartości) a niezdefiniowaną (bez podanej wartości). * Istnieje nawet przydatny operator dla niej '! = Null' (nieprzewidziany) – Esailija

+0

Jedyny przypadek Mogę myśleć o testowaniu, jeśli przeglądarka obsługuje określony typ zdarzenia. Na przykład 'if (typeof onbeforepaste ==" undefined ")', aby zobaczyć, czy 'onBeforePaste' jest obsługiwany. Nawet wtedy nie robi to prawdziwej różnicy, ponieważ możesz przypisywać zdarzenia, które tylko chcesz (po prostu nie zrobią niczego, jeśli nie są obsługiwane). –

+0

W takim przypadku przetestowałbym '" onbeforepaste "w dokumencie', aby sprawdzić istnienie właściwości. – Esailija

19

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

Wyniki twojego JSON powinny odzwierciedlać to, co jest używane i potrzebne twojej aplikacji w specyficznym kontekście korzystania z danych JSON.

+4

W JSON nie ma "nieokreślonego", więc myślę, że pyta tylko czy dodać "puste" właściwości, czy nie - '{" prop ": undefined}' różni się od '{ } '. – Bergi

+0

Zgadzam się, próbuję wyjaśnić, że na końcu odbierającym, jeśli szuka określonej właściwości, która ma być ustawiona na zero, nie będzie. Będzie nieokreślone, jeśli zostanie pominięte. – Brad

10

Powinieneś go koniecznie 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 pozbawiona znaczenia, a undefined oznacza, że ​​właściwość nie istnieje.

Z drugiej strony, jeśli nie ma potrzeby, aby ktokolwiek dokonał tego rozróżnienia, należy go opuścić.

71

Jestem fanem zawsze włączania null, ponieważ ma to znaczenie. Podczas pomijania właściwości pozostawia niejednoznaczność.

Dopóki uzgodniony jest twój protokół z serwerem, którykolwiek z powyższych może działać, ale jeśli przekazujesz wartości zerowe z serwera, uważam, że twoje interfejsy API są bardziej elastyczne później.

Należy również wspomnieć, że funkcja hasOwnProperty javascript daje więcej informacji.

/* 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

Dokładnie, więcej ludzi musi zrozumieć różnicę między "", wartością null i nieokreśloną. Odpowiedź na to pytanie zależy od wymagań użytkowników. – Jacob

+11

+1. Osoba na drugim końcu (kto napisał kod) będzie lepiej obsługiwana przez wyraźne wartości. Mogą nie pisać JavaScript ;-) – Steve11235

+2

Należy zauważyć, że sprawdzanie wartości NULL nie działa z opcją ==, === jest wymagane (ponieważ undefined == null)! – Tommy

0

Myślę, że to nie ma znaczenia, gdy używasz JSON jako danych za doświadczeniem użytkownika.

Różnica pojawia się w plikach konfiguracyjnych JSON, kiedy użytkownik powinien edytować coś ręcznie. Kiedy używasz pierwszego przykładu, dajesz użytkownikowi podpowiedź na temat konfiguracji.

+1

Czy mógłbyś jeszcze bardziej rozwinąć swoją odpowiedź, dodając nieco więcej opisu dostarczonego rozwiązania? – abarisone

Powiązane problemy