null oder Feld weglassen
Fazit: `null` sagt, das Feld existiert ohne Wert; Weglassen sagt, das Feld existiert nicht. PATCH-Bodies, Konfigurationszusammenführung und Formularvorbelegung sind die Stellen, an denen der Unterschied beißt.
Kurz gesagt: Senden Sie null, wenn der Konsument „geleert“ von „unangetastet“ unterscheiden muss – in einem PATCH-Body lässt Weglassen das Feld unangetastet und ein ausdrückliches null leert es – und halten Sie pro Feld eine Konvention, damit Antworten und Konfigurationszusammenführungen stabil bleiben.
Der Unterschied
{ "nickname": null }
Vorhanden, leer. Der Konsument weiß, das Feld wurde ausdrücklich geleert.
{ }
Fehlend. Der Konsument kann „nie gesetzt“ nicht von „nicht unterstützt“ unterscheiden.
In JavaScript ist die Unterscheidung konkret:
'nickname' in obj // false — absent
obj.nickname === null // true — present and null
obj.nickname === undefined // true — both cases
Wo es zählt
PATCH-Bodies. {"nickname": null} leert den Nickname. {} ändert nichts. Behandelt der Handler „null“ und „fehlend“ gleich, können Nutzer das Feld nie leeren – sie können nur einen leeren String setzen, was etwas anderes ist.
Implementieren Sie mit Schlüsselpräsenz, nicht Wert:
if (Object.hasOwn(patch, 'nickname')) {
target.nickname = patch.nickname; // null allowed
}
Konfigurationszusammenführung. Weglassen erbt den Standard; null deaktiviert ihn ausdrücklich. Genau so verhalten sich Helm- und Kubernetes-Werte.
Formularvorbelegung. Ein null rendert als leer, und ein fehlendes Feld auch, aber das Absenden unterscheidet sich: hatte einen Wert, jetzt geleert → null senden; nie ausgefüllt → weglassen. Ohne die Unterscheidung sieht Leeren identisch zu Nicht-Anfassen aus.
Konventionen
| Situation | Konvention |
|---|---|
| Response-Bodies | null behalten; stabile Form, einfachere Typen |
| PATCH-Anfragen | null leert, Weglassen bewahrt |
| PUT (vollständiger Ersatz) | Weglassen bedeutet löschen – das ganze Dokument wird ersetzt |
| Konfigurationszusammenführung | Weglassen = Standard, null = deaktiviert |
| Datenbank | null für unbekannt oder nicht zutreffend; '' für bekannt-leer |
Response-Formen stabil halten. Eine Liste, in der manche Elemente avatar tragen und andere nicht, erzwingt 'avatar' in item-Prüfungen an jeder Aufrufstelle. avatar: null ist leichter zu konsumieren.
Drei Dinge, die man nicht tun sollte
"" nicht für null verwenden. Ein leerer Nickname und ein nicht gesetzter Nickname sind in den meisten Domänen verschiedene Zustände.
0 oder -1 nicht als Sentinel verwenden. Null ist eine legitime Zahl, und der Sentinel verfälscht jeden Durchschnitt, den Sie berechnen.
Konventionen nicht pro Endpunkt mischen. Zwei Konventionen bedeuten zwei Code-Pfade in jedem Client.
FAQ
Was entscheidet zwischen null und einem weggelassenen Feld?
Fragen Sie, ob der Konsument „ausdrücklich geleert“ von „nie gesetzt“ unterscheiden muss. In einem PATCH-Body muss er es, also leert null und Abwesenheit bewahrt; in Antworten macht das Beibehalten von null die Form stabil und die Client-Typen einfacher.
Wie unterscheidet ein PATCH-Endpunkt Leeren von Unangetastetlassen?
Prüfen Sie die Schlüsselpräsenz, nicht den Wert: Object.hasOwn(patch, 'nickname') sagt Ihnen, dass das Feld gesendet wurde, und erst dann weisen Sie es zu, null eingeschlossen. Behandelt der Handler null und fehlend gleich, können Nutzer das Feld nie leeren und nur auf einen leeren String zurückfallen.
Warum sollten Response-Bodies null behalten?
Eine stabile Form bedeutet, Clients brauchen keine 'avatar' in item-Prüfung für jeden optionalen Schlüssel. Tragen manche Listenelemente avatar und andere lassen es weg, wird diese Prüfung an jeder Aufrufstelle dupliziert und ist leicht falsch.