null o omettere il campo
In sintesi: `null` dice che il campo esiste senza valore; ometterlo dice che il campo non esiste. I corpi PATCH, il merge di configurazione e il precompilamento dei form sono i punti in cui la differenza morde.
In sintesi: invia null quando il consumatore deve distinguere "svuotato" da "non toccato" — in un corpo PATCH, l'omissione lascia il campo com'è e un null esplicito lo svuota — e mantieni una sola convenzione per campo così risposte e merge di configurazione restano stabili.
La differenza
{ "nickname": null }
Presente, vuoto. Il consumatore sa che il campo è stato esplicitamente svuotato.
{ }
Assente. Il consumatore non può distinguere "mai impostato" da "non supportato".
In JavaScript la distinzione è concreta:
'nickname' in obj // false — absent
obj.nickname === null // true — present and null
obj.nickname === undefined // true — both cases
Dove conta
Corpi PATCH. {"nickname": null} svuota il nickname. {} non cambia nulla. Se il handler tratta "null" e "mancante" allo stesso modo, gli utenti non possono mai svuotare il campo — possono solo impostare una stringa vuota, che è una cosa diversa.
Implementa in base alla presenza della chiave, non al valore:
if (Object.hasOwn(patch, 'nickname')) {
target.nickname = patch.nickname; // null allowed
}
Merge di configurazione. L'omissione eredita il default; null lo disattiva esplicitamente. È esattamente come si comportano i valori di Helm e Kubernetes.
Precompilamento dei form. Un null viene renderizzato come vuoto e anche un campo mancante, ma l'invio differisce: aveva un valore, ora svuotato → invia null; mai compilato → ometti. Senza la distinzione, svuotare sembra identico a non aver toccato.
Convenzioni
| Situazione | Convenzione |
|---|---|
| Corpi di risposta | Mantieni null; forma stabile, tipi più semplici |
| Richieste PATCH | null svuota, l'omissione conserva |
| PUT (sostituzione completa) | L'omissione significa eliminare — l'intero documento viene sostituito |
| Merge di configurazione | Omissione = default, null = disattivato |
| Database | null per sconosciuto o non applicabile; '' per vuoto noto |
Mantieni stabili le forme delle risposte. Una lista in cui alcuni elementi portano avatar e altri no costringe a controlli 'avatar' in item in ogni punto di chiamata. avatar: null è più facile da consumare.
Tre cose da non fare
Non usare "" per null. Un nickname vuoto e un nickname non impostato sono stati diversi nella maggior parte dei domini.
Non usare 0 o -1 come sentinelle. Zero è un numero legittimo, e la sentinella corrompe ogni media che calcoli.
Non mescolare convenzioni per endpoint. Due convenzioni significano due percorsi di codice in ogni client.
FAQ
Cosa decide tra null e un campo omesso?
Chiediti se il consumatore deve distinguere "esplicitamente svuotato" da "mai impostato". In un corpo PATCH deve, quindi null svuota e l'assenza conserva; nelle risposte, mantenere null rende la forma stabile e i tipi del client più semplici.
Come fa un endpoint PATCH a distinguere lo svuotamento dal lasciare com'è?
Controlla la presenza della chiave, non il valore: Object.hasOwn(patch, 'nickname') ti dice che il campo è stato inviato, e solo allora assegnalo, null incluso. Se il handler tratta null e mancante allo stesso modo, gli utenti non possono mai svuotare il campo e possono solo ripiegare su una stringa vuota.
Perché i corpi di risposta dovrebbero mantenere null?
Una forma stabile significa che i client non hanno bisogno di un controllo 'avatar' in item per ogni chiave opzionale. Quando alcuni elementi della lista portano avatar e altri lo omettono, quel controllo viene duplicato in ogni punto di chiamata ed è facile da sbagliare.