Json — необязательный вложенный документ

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

например (Это всего лишь пример, настоящий выглядит иначе, но я не могу его опубликовать, пример скопирован из: Как представить вложенные документы в массиве JSON как коллекцию Java с помощью Jackson?): Поддокумент Adreess присутствует не во всех документ, который я получаю.

 {
  "attributes": {
    "type": "Lead",
    "url": "/services/data/v30.0/sobjects/Lead/00Qi000000Jr44XEAR"
  },
  "Id": "00Qi000000Jr44XEAR",
  "Name": "Kristen Akin",
  "Address": {
      "city": null,
      "country": "USA",
      "state": "CA",
      "stateCode": null,
      "street": null
  },
  "Phone": "(434) 369-3100"
}

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

{
  "attributes": {
    "type": "Lead",
    "url": "/services/data/v30.0/sobjects/Lead/00Qi000000Jr44XEAR"
  },
  "Id": "00Qi000000Jr44XEAR",
  "Name": "Kristen Akin",
  "Address": "",
  "Phone": "(434) 369-3100"
}

Я хочу предложить лучшие способы, и мне интересно, какой из них лучший?

  1. Полностью исключить поддокумент адреса
  2. Адрес получения: нулевой
  3. Адрес получения: {}
  4. Адрес получения: {город: null, страна: null, ...}
  5. что-нибудь еще

Лично я бы пошел с Nr. 3, потому что я все еще получаю (под)документ и могу обращаться с ним обычным образом. Что-нибудь говорит против этого или есть какие-то лучшие практики для этой ситуации?

Заранее спасибо.

С наилучшими пожеланиями.


person Salfii    schedule 29.07.2020    source источник


Ответы (2)


Иди с 3.

  1. Полностью исключить поддокумент адреса

Будет работать для многих инструментов десериализации, но трудно определить структуру и легко определить, отсутствует ли что-то при отладке.

  1. Адрес получения: нулевой

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

  1. Адрес получения: {}

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

  1. Адрес получения: {город: null, страна: null, ...}

Не делай этого. Это дает вам более подробную информацию о сложном объекте, но вы не можете легко определить, был ли адрес добавлен непреднамеренно, или если партнер API случайно отправляет неполные адресные данные, или если неполные данные действительны на их стороне.

person Patrick    schedule 29.07.2020

Я всегда различаю значения, которые:

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

Я бы предпочел эти варианты:

1.: если он опущен, он не определен и означает, что приложение должно обрабатывать неопределенные значения. Особенно для необязательных значений вы должны знать об обработке неопределенных значений.

3.: если он пуст, у вас все еще есть действующая адресная книга, но пустая, что упрощает обработку в коде.

Чего я бы избегал:

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

5.: изменение типа данных на также плохо, потому что для типизированных языков это затруднит анализ, потому что он ожидает объект, но получает строку.

person Denis Loh    schedule 29.07.2020
comment
Спасибо за ваше мнение, ваш ответ также правильный. Я только что принял первый ответ. - person Salfii; 29.07.2020