Каков отраслевой стандарт в сериализации пустых атрибутов в службах на основе REST?

Question

Недавно с моим коллегой шла дискуссия о надлежащих отраслевых стандартах, связанных с резонансами в формате XML / JSON, с элементами с нулевыми значениями.Я считаю, что нужно игнорировать / не включать элементы в ответы XML и JSON, если конкретный элемент имеет нулевые значения.Я считаю, что это уменьшит размер полезной нагрузки и уменьшит пропускную способность при передаче.

Где аргумент моих коллег должен включать все атрибуты / элементы, определенные в JSON / XML, независимо от того, есть ли значение или нет.

В идеале это похоже на

<name>John Doe</name>
 vs
<name>John Doe</name>
<DOB/>

Аналогично

{
  "name":"John Doe"
}
vs
{
   "name":"John Doe",
   "DOB":null
}

Какой правильный подход и почему?

Спасибо

Answer 1

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

Answer 2

<name>John Doe</name>
 vs
<name>John Doe</name>
<DOB/>

Осторожно! Эти два представления не совсем эквивалентны. <DOB/> обозначает пустой элемент ; это эквивалентно <DOB></DOB>. Пустые и нулевые не являются взаимозаменяемыми, поэтому у нас есть и 204 No Content и 404 Not Found, и -s и -e.

Какой правильный подход и почему?

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

В распределенной системе, где клиенты и серверы развертываются с разной частотой, обычно расширяют схему с дополнительной семантикой в ​​течение срока действия контракта. Но если клиенты и серверы развернуты независимо, у вас могут возникнуть ситуации, когда клиент и сервер понимают разные версии одной и той же схемы. Поэтому мы должны быть осторожны с прямой и обратной совместимостью, а также с ограничениями на наши изменения, необходимые для того, чтобы все работало.

(Конечно, в конечном итоге мы захотим внести несовместимые изменения. Поэтому нам нужно будет ввести новую схему сообщений, а это, в свою очередь, означает, что нам нужно думать о жизненных циклах ).

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

Так что для дополнительного случая должен ли производитель, который знает о дополнительном поле, всегда включать его в сообщение? Я не знаю каких-либо опубликованных аргументов в пользу этого, за исключением общих советов, которые явно улучшают неявные.