Чи повинен JSON включати нульові значення [закрито]


89

Я створюю API, який повертає результати як JSON. Чи існує поточна найкраща практика щодо того, чи слід нам включати ключі в результат, коли значення дорівнює нулю? Наприклад:

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

або

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

Оскільки другий менше, я схиляюся до цього стилю, але я не впевнений, чи є якийсь кращий стиль чи ні. З точки зору клієнта здається, що обидва стилі були б функціонально еквівалентними. Будь-які плюси чи мінуси у кожного?


6
Відповісти на це правильно неможливо. Правильна відповідь залежить від вимог заявки. OP просто вибрав відповідь, яка відповідає його вимогам. Якщо ваша програма повинна мати можливість розрізнити, знаючи, чи є "isbn" нульовим, чи якщо "isbn", можливо, не було надіслано із сервера з іншої причини, вам потрібно включити його.
Джей

@Jacob Хоча я цього не сказав, я мав намір з цим питанням повернути "повний" JSON, що представляє відповідь. Коли клієнт може припустити, що між цими двома підходами функціональної різниці немає. Якщо API вибірково не повертає ключі / значення, тоді так, це матиме велике значення, який підхід було застосовано.
jjathman

перевага першого подання полягає в тому, що схема об'єктів зберігається, наявність властивості не є однозначною на основі даних. у другому форматі ця інформація втрачається. Специфікація JSON як така не вимагає жодного формату AFAIK
Surya Pratap

Відповіді:


32

Другий заощадить невелику кількість на пропускній здатності, але якби це турбувало, ви б також використовували індексовані масиви, а не заповнювали JSON ключами. Очевидно, що ["Foo Bar","Joe Blow"]це набагато коротше, ніж у вас зараз.

Що стосується зручності використання, я не думаю, що це має різницю. В обох випадках if(json.isbn)перейде до else. Зазвичай немає необхідності розрізняти null(немає вартості) та undefined(немає заданої вартості).


7
+1 для Зазвичай немає потреби розрізняти нуль (без значення) та невизначений (без заданого значення). Існує навіть зручний оператор != null(не суворо призначений)
Есайлія

Єдиний випадок, про який я можу подумати, - це тестування, якщо браузер підтримує певний тип подій. Наприклад, if( typeof onbeforepaste == "undefined")щоб перевірити, чи onBeforePasteпідтримується. Навіть тоді це не має ніякої реальної різниці, оскільки ви можете призначати події все, що хочете (вони просто нічого не зроблять, якщо не підтримуються).
Niet the Dark Absol

6
З точки зору збереження переданих байтів, стиснення набагато важливіше, ніж такі речі, як індексовані масиви. web-resource-optimization.blogspot.no/2011/06/… Переконайтеся, що це перше, що ви робите. У більшості випадків додавання таких речей, як індексовані масиви, - це те, що я назвав би передчасною оптимізацією. Якщо ви не надсилаєте ВЕЛИКИЙ обсяг даних. Це також вимагає додаткового аналізу, додаючи додаткові складності додатку. Gzipping легко виконується браузером. (припускаючи, що клієнт є браузером)
Мартін Хансен,

3
Оскільки HTTPS стає нормою дня (принаймні для додатків з великою базою користувачів), стиснення йде на мету. Дивіться en.wikipedia.org/wiki/CRIME_%28security_exploit%29
Gaurav Vaish 21.03.14

6
Я б насправді -1 це для "Зазвичай немає потреби розрізняти нуль", якби я мав репутацію. З двох причин: 1. причини для розрізнення існують, і вони не рідкісні. 2. найкраща практика - завжди мати значення "чітко визначені", що означає завжди запобігати будь-яким неясностям - 2 значення 1 значення - це завжди зло - це повинно бути досить чітко
Срнечек

80

Я прихильник завжди включати null явно, оскільки це несе значення. Опускаючи властивість, залишається двозначність.

Поки ваш протокол із сервером узгоджено, будь-що з наведеного вище може працювати, але якщо ви передасте значення null із сервера, я вважаю, що це робить ваші API більш гнучкими згодом.

Слід також зазначити, що функція javascript hasOwnProperty дає вам подальше розуміння.

/* 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
Точно, більше людей повинні розуміти різницю між "", нульовим та невизначеним. Відповідь на це запитання залежить від вимог користувачів.
Джей

13
+1. Людина з іншого боку (хто написав код) буде краще обслуговуватися явними значеннями. Можливо, вони не пишуть JavaScript ;-)
Steve11235

2
Зверніть увагу, що перевірка проти null не працює з ==, === необхідна (оскільки undefined == null)!
Томмі

саме перша частина прийнятої відповіді є настільки неправильною ...
Срнечек

Я б писав "propertyName" in objectFromJSONзамість objectFromJSON.hasOwnProperty("propertyName"). Крім того, якщо ви наполягаєте на використанні, hasOwnPropertyнапишіть Object.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")для безпеки.
Aadit M Shah

22

У JavaScript nullозначає щось зовсім інше, ніж undefined.

Вихідні дані JSON повинні відображати те, що використовується та потрібно вашому додатку в конкретному контексті використання даних JSON.


5
У "JSON" немає "невизначеного", тому, я думаю, він запитує лише, включати "порожні" властивості чи ні - {"prop":undefined}це відрізняється від {}.
Бергі,

Погоджено, я намагаюся пояснити, що на кінці, що отримує, якщо він шукає конкретну властивість, для якої має значення null, цього не буде. Це буде невизначеним, якщо його виключити.
Бред

11

Ви обов’язково повинні включити його, якщо є потреба розрізнити nullі undefinedоскільки вони мають два різні значення в Javascript. Ви можете думати про nullзначення властивості невідомо чи безглуздо, а undefinedяк значення властивість не існує.

З іншого боку, якщо нікому не потрібно робити таку відмінність, тоді продовжуйте і залишайте це поза увагою.


0

Я думаю, що немає ніякої різниці, коли ви використовуєте JSON як дані, що описують досвід користувачів.

Різниця з’являється у файлах JSON-config, коли користувач повинен щось редагувати вручну. Коли ви використовуєте перший приклад, ви даєте користувачеві деяку підказку щодо конфігурації.


1
Не могли б ви детальніше розробити свою відповідь, додавши трохи більше опису запропонованого вами рішення?
абарізон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.