null чи пропустити поле
Головне: `null` каже, що поле існує без значення; пропуск каже, що поле не існує. Тіла PATCH, злиття конфігурації й попереднє заповнення форм — ось де різниця кусає.
Коротко: надсилайте null, коли споживач мусить відрізнити «очищено» від «недоторкано» — у тілі PATCH пропуск лишає поле недоторканим, а явний null очищає його — і тримайте одну конвенцію на поле, щоб відповіді й злиття конфігурації лишалися стабільними.
Різниця
{ "nickname": null }
Присутнє, порожнє. Споживач знає, що поле явно очищено.
{ }
Відсутнє. Споживач не може відрізнити «ніколи не встановлювали» від «не підтримується».
У JavaScript розрізнення конкретне:
'nickname' in obj // false — відсутнє
obj.nickname === null // true — присутнє й null
obj.nickname === undefined // true — обидва випадки
Де це важливо
Тіла PATCH. {"nickname": null} очищає псевдонім. {} не змінює нічого. Якщо обробник трактує «null» і «відсутній» однаково, користувачі ніколи не можуть очистити поле — вони можуть лише встановити порожній рядок, що є іншою річчю.
Реалізуйте за наявністю ключа, а не за значенням:
if (Object.hasOwn(patch, 'nickname')) {
target.nickname = patch.nickname; // null дозволено
}
Злиття конфігурації. Пропуск успадковує типове; null явно його вимикає. Саме так поводяться значення Helm і Kubernetes.
Попереднє заповнення форми. null відображається як порожнє, як і відсутнє поле, але надсилання різниться: мало значення, тепер очищено → надіслати null; ніколи не заповнювали → пропустити. Без розрізнення очищення виглядає ідентичним до недоторканості.
Конвенції
| Ситуація | Конвенція |
|---|---|
| Тіла відповідей | Тримайте null; стабільна форма, простіші типи |
| Запити PATCH | null очищає, пропуск зберігає |
| PUT (повна заміна) | Пропуск означає видалення — весь документ замінюється |
| Злиття конфігурації | Пропуск = типове, null = вимкнено |
| База даних | null для невідомого чи непридатного; '' для відомо-порожнього |
Тримайте форми відповідей стабільними. Список, де одні елементи несуть avatar, а інші ні, змушує перевірки 'avatar' in item на кожному місці виклику. avatar: null простіше споживати.
Три речі, яких не робити
Не використовуйте "" замість null. Порожній псевдонім і невстановлений псевдонім — різні стани в більшості доменів.
Не використовуйте 0 чи -1 як сторожові значення. Нуль — законне число, а сторожове значення псує кожне середнє, яке ви обчислюєте.
Не змішуйте конвенції між кінцевими точками. Дві конвенції означають два шляхи в коді кожного клієнта.
Часті питання
Що вирішує між null і пропущеним полем?
Запитайте, чи споживачу треба розрізняти «явно очищено» від «ніколи не встановлювали». У тілі PATCH треба, тож null очищає, а відсутність зберігає; у відповідях збереження null робить форму стабільною, а типи клієнта простішими.
Як кінцева точка PATCH відрізняє очищення від недоторканості?
Перевіряйте наявність ключа, а не значення: Object.hasOwn(patch, 'nickname') каже, що поле надіслано, і лише тоді присвоюйте його, включно з null. Якщо обробник трактує null і відсутність однаково, користувачі ніколи не можуть очистити поле й можуть лише відкотитися до порожнього рядка.
Чому тіла відповідей мають тримати null?
Стабільна форма означає, що клієнтам не потрібна перевірка 'avatar' in item для кожного необовʼязкового ключа. Коли одні елементи списку несуть avatar, а інші його пропускають, та перевірка дублюється на кожному місці виклику й легко помиляється.