null یا حذف فیلد

جمع‌بندی: وقتی مصرف‌کننده باید «پاک شد» را از «دست نخورد» تشخیص دهد null بفرستید — در بدنه PATCH، غیبت فیلد را دست‌نخورده می‌گذارد و null صریح پاکش می‌کند — و برای هر فیلد یک قرارداد نگه دارید تا پاسخ‌ها و ادغام‌های پیکربندی پایدار بمانند.

تفاوت

复制{ "nickname": null }

حاضر، خالی. مصرف‌کننده می‌داند فیلد صریحاً پاک شده.

复制{ }

غایب. مصرف‌کننده نمی‌تواند «هرگز تنظیم نشد» را از «پشتیبانی نمی‌شود» تشخیص دهد.

در جاوااسکریپت تمایز مشخص است:

复制'nickname' in obj          // false — absent
obj.nickname === null      // true  — present and null
obj.nickname === undefined // true  — both cases

کجا مهم است

بدنه‌های PATCH. {"nickname": null} نام مستعار را پاک می‌کند. {} چیزی را تغییر نمی‌دهد. اگر handler «null» و «گم‌شده» را یکسان بگیرد، کاربران هرگز نمی‌توانند فیلد را پاک کنند — فقط می‌توانند رشته خالی بگذارند که چیز دیگری است.

با حضور کلید پیاده کنید، نه مقدار:

复制if (Object.hasOwn(patch, 'nickname')) {
  target.nickname = patch.nickname;   // null allowed
}

ادغام پیکربندی. حذف پیش‌فرض را به ارث می‌برد؛ null صریحاً غیرفعالش می‌کند. دقیقاً همان‌گونه که مقادیر Helm و Kubernetes رفتار می‌کنند.

پیش‌پر کردن فرم. null به‌صورت خالی نمایش داده می‌شود و فیلد گم‌شده هم همین‌طور، اما ارسال متفاوت است: مقدار داشت، اکنون پاک شده → null بفرستید؛ هرگز پر نشد → حذف کنید. بدون این تمایز، پاک کردن مانند دست نزدن به نظر می‌رسد.

قراردادها

شکل پاسخ‌ها را پایدار نگه دارید. فهرستی که برخی آیتم‌ها avatar دارند و برخی نه، در هر نقطه فراخوانی بررسی 'avatar' in item را تحمیل می‌کند. avatar: null مصرف‌ش ساده‌تر است.

سه کاری که نکنید

برای null از "" استفاده نکنید. نام مستعار خالی و نام مستعار تنظیم‌نشده در بیشتر دامنه‌ها حالت‌های متفاوتی‌اند.

از 0 یا -1 به‌عنوان نگهبان استفاده نکنید. صفر عدد مشروعی است و نگهبان هر میانگینی را که محاسبه می‌کنید خراب می‌کند.

قراردادها را بین endpointها مخلوط نکنید. دو قرارداد یعنی دو مسیر کد در هر کلاینت.

پرسش‌های متداول

چه چیزی بین null و فیلد حذف‌شده تصمیم می‌گیرد؟

بپرسید آیا مصرف‌کننده باید «صریحاً پاک شد» را از «هرگز تنظیم نشد» تشخیص دهد. در بدنه PATCH باید، پس null پاک می‌کند و غیبت حفظ؛ در پاسخ‌ها، نگه داشتن null شکل را پایدار و نوع‌های کلاینت را ساده‌تر می‌کند.

endpoint PATCH چگونه پاک کردن را از دست نزده تشخیص می‌دهد؟

حضور کلید را بررسی کنید، نه مقدار: Object.hasOwn(patch, 'nickname') می‌گوید فیلد فرستاده شده و فقط آن‌گاه انتساب دهید، null هم شامل. اگر handler null و گم‌شده را یکسان بگیرد، کاربران هرگز نمی‌توانند فیلد را پاک کنند و فقط می‌توانند به رشته خالی برگردند.

چرا بدنه‌های پاسخ باید null را نگه دارند؟

شکل پایدار یعنی کلاینت‌ها برای هر کلید اختیاری به بررسی 'avatar' in item نیاز ندارند. وقتی برخی آیتم‌های فهرست avatar دارند و برخی حذفش می‌کنند، آن بررسی در هر نقطه فراخوانی تکرار می‌شود و اشتباه‌شدنش آسان است.

مطالعه بیشتر

• پاسخ API باید چه ساختاری داشته باشد
• JSON Pointer، Patch و Merge Patch