null ou omettre le champ
L’essentiel : `null` dit que le champ existe sans valeur ; omettre dit que le champ n'existe pas. Corps PATCH, fusion de configuration et préremplissage de formulaire sont là où la différence mord.
L'essentiel : envoyez null quand le consommateur doit distinguer « effacé » de « intact » — dans un corps PATCH, l'omission laisse le champ tranquille et un null explicite l'efface — et gardez une convention par champ pour que les réponses et les fusions de configuration restent stables.
La différence
{ "nickname": null }
Présent, vide. Le consommateur sait que le champ a été explicitement effacé.
{ }
Absent. Le consommateur ne peut pas distinguer « jamais défini » de « non pris en charge ».
En JavaScript la distinction est concrète :
'nickname' in obj // false — absent
obj.nickname === null // true — present and null
obj.nickname === undefined // true — both cases
Où cela compte
Corps PATCH. {"nickname": null} efface le pseudo. {} ne change rien. Si le gestionnaire traite « null » et « manquant » comme la même chose, les utilisateurs ne peuvent jamais effacer le champ — ils ne peuvent que définir une chaîne vide, ce qui est différent.
Implémentez avec la présence de clé, pas la valeur :
if (Object.hasOwn(patch, 'nickname')) {
target.nickname = patch.nickname; // null allowed
}
Fusion de configuration. L'omission hérite du défaut ; null le désactive explicitement. C'est exactement le comportement des valeurs Helm et Kubernetes.
Préremplissage de formulaire. Un null s'affiche comme vide, et un champ manquant aussi, mais la soumission diffère : avait une valeur, maintenant effacé → envoyer null ; jamais rempli → omettre. Sans la distinction, effacer ressemble à ne pas toucher.
Conventions
| Situation | Convention |
|---|---|
| Corps de réponse | Garder null ; forme stable, types plus simples |
| Requêtes PATCH | null efface, l'omission préserve |
| PUT (remplacement complet) | L'omission signifie suppression — tout le document est remplacé |
| Fusion de configuration | Omission = défaut, null = désactivé |
| Base de données | null pour inconnu ou non applicable ; '' pour connu-vide |
Gardez les formes de réponse stables. Une liste où certains éléments portent avatar et d'autres non oblige à des vérifications 'avatar' in item à chaque site d'appel. avatar: null est plus facile à consommer.
Trois choses à ne pas faire
N'utilisez pas "" pour null. Un pseudo vide et un pseudo non défini sont des états différents dans la plupart des domaines.
N'utilisez pas 0 ou -1 comme sentinelles. Zéro est un nombre légitime, et la sentinelle corrompt chaque moyenne que vous calculez.
Ne mélangez pas les conventions par point de terminaison. Deux conventions signifient deux chemins de code dans chaque client.
FAQ
Qu'est-ce qui décide entre null et un champ omis ?
Demandez si le consommateur doit distinguer « explicitement effacé » de « jamais défini ». Dans un corps PATCH il le doit, donc null efface et l'absence préserve ; dans les réponses, garder null rend la forme stable et les types client plus simples.
Comment un point de terminaison PATCH distingue-t-il l'effacement du laisser-tranquille ?
Vérifiez la présence de clé, pas la valeur : Object.hasOwn(patch, 'nickname') vous dit que le champ a été envoyé, et seulement alors assignez-le, null inclus. Si le gestionnaire traite null et manquant comme la même chose, les utilisateurs ne peuvent jamais effacer le champ et ne peuvent que se rabattre sur une chaîne vide.
Pourquoi les corps de réponse devraient-ils garder null ?
Une forme stable signifie que les clients n'ont pas besoin d'une vérification 'avatar' in item pour chaque clé facultative. Quand certains éléments de liste portent avatar et d'autres l'omettent, cette vérification est dupliquée à chaque site d'appel et facile à rater.