Должен ли JSON включать нулевые значения [закрыто]


89

Я создаю API, который возвращает результаты в формате JSON. Есть ли в настоящее время лучший способ включения ключей в результат, когда значение равно нулю? Например:

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

или

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

Поскольку второй меньше, я склоняюсь к этому стилю, но не уверен, есть ли какой-то предпочтительный стиль или нет. С точки зрения клиента кажется, что оба стиля будут функционально эквивалентны. Есть ли плюсы или минусы для каждого?


6
Правильно ответить на это невозможно. Правильный ответ зависит от требований приложения. ОП просто выбрал ответ, который соответствует его требованиям. Если вашему приложению необходимо иметь возможность различать между знанием того, является ли "isbn" нулевым, и тем, что "isbn" не был отправлен с сервера по другой причине, вам необходимо включить его.
Джей

@Jacob Хотя я этого не говорил, я хотел задать этот вопрос, чтобы возвращался «полный» JSON, представляющий ответ. Когда клиент может предположить, что между этими двумя подходами нет функциональной разницы. Если бы API выборочно не возвращал ключи / значения, тогда да, это имело бы большое значение, какой подход был выбран.
jjathman

Преимущество первого представления состоит в том, что схема объекта сохраняется, наличие свойства не является неоднозначным на основе данных. во втором формате эта информация теряется. Спецификация JSON как таковая не требует ни одного формата AFAIK
Сурья Пратап

Ответы:


32

Второй вариант позволит немного сэкономить на пропускной способности, но если бы это было проблемой, вы также могли бы использовать индексированные массивы вместо заполнения JSON ключами. Ясно, ["Foo Bar","Joe Blow"]что намного короче того, что есть сейчас.

Что касается удобства использования, я не думаю, что это имеет значение. В обоих случаях if(json.isbn)произойдет переход к файлу else. Обычно нет необходимости различать null(нет значения) и undefined(нет значения).


7
+1 для Обычно нет необходимости различать null (нет значения) и undefined (нет значения). Для этого есть даже удобный оператор != null(нестрогий)
Esailija

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

6
С точки зрения сохранения передаваемых байтов сжатие намного важнее, чем такие вещи, как индексированные массивы. web-resource-optimization.blogspot.no/2011/06/… Убедитесь, что это первое, что вы делаете. В большинстве случаев добавление таких вещей, как индексированные массивы, поверх этого - это то, что я бы назвал преждевременной оптимизацией. Если вы не отправляете БОЛЬШИЕ объемы данных. Это также требует дополнительного анализа, усложняющего ваше приложение. Gzip-архивирование выполняется браузером без проблем. (при условии, что клиент - это браузер)
Мартин Хансен,

3
Поскольку HTTPS становится нормой дня (по крайней мере, для приложений с большой пользовательской базой), сжатие идет на спад. См. En.wikipedia.org/wiki/CRIME_%28security_exploit%29
Gaurav Vaish

6
Если бы у меня была репутация, я бы фактически -1 это за «Обычно нет необходимости различать null». По двум причинам: 1. Причины различать существуют, и они не редки 2. Лучшая практика - всегда иметь значения «четко определенные», что означает всегда предотвращать любые двусмысленности - 2 значения одного значения всегда плохо - это должно быть довольно ясно ..
Срнечек

80

Я сторонник того, чтобы всегда явно указывать null, поскольку это имеет смысл. Если пропустить свойство, остается двусмысленность.

Пока ваш протокол с сервером согласован, все вышеперечисленное может работать, но если вы передадите с сервера значения NULL, я считаю, что это сделает ваши API более гибкими позже.

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

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

13
+1. Для человека на другом конце (написавшего код) лучше использовать явные значения. Возможно, они не пишут JavaScript ;-)
Steve11235

2
Обратите внимание, что проверка на null не работает с ==, === требуется (потому что undefined == null)!
Tommy

именно первая часть принятого ответа настолько неверна ...
Срнечек

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

22

В JavaScript это nullозначает нечто совершенно иное, чем undefined.

Выходные данные JSON должны отражать то, что используется и требуется вашим приложением в конкретном контексте использования данных JSON.


5
В JSON нет "undefined", поэтому я думаю, что он спрашивает только, включать ли "пустые" свойства или нет - {"prop":undefined}отличается от {}.
Берги

Согласен, я пытаюсь объяснить, что на принимающей стороне, если он ищет для определенного свойства значение null, его не будет. Если не указывать, он будет неопределенным.
Брэд

11

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

С другой стороны, если кому-либо нет необходимости проводить такое различие, оставьте это в стороне.


0

Я думаю, нет никакой разницы, когда вы используете JSON в качестве данных, лежащих в основе опыта пользователя.

Разница проявляется в файлах конфигурации JSON, когда пользователь должен что-то отредактировать вручную. Когда вы используете первый пример, вы даете пользователю некоторую подсказку о конфигурации.


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