Чи повинен 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.