درخواست API را مطابق نوع خطا و قرارداد همان عملیات دوباره بفرستید. پایان مهلت پاسخ یا timeout ثابت نمی‌کند عملیات نوشتن انجام نشده است. تکرار فوری و بی‌حد درخواست نیز می‌تواند فشار بر سامانه را بیشتر کند.
تفکیک نتایج خواندن و نوشتن
برای عملیاتی که حالت را تغییر می‌دهد، قبل از ارسال مجدد تعیین کنید که آیا تکمیل شده است یا نه. اگر API روش مستندی برای جلوگیری از اثر تکراری یا idempotency دارد، مطابق همان روش عمل کنید؛ وجود آن را فرض نکنید.
تأخیر و سقف تلاش مجدد را از قرارداد بگیرید
راهنمایی‌های ارسال مجدد ارائه‌شده توسط سرویس‌دهنده و سیگنال‌های تأخیر پشتیبانی‌شده را اعمال کنید. تلاش‌ها را ثبت کنید و عملیات‌های حل‌نشده را برای تطبیق نگه دارید، نه برای تکرار بی‌پایان.
| موضوع بررسی | مدرک یا دادهٔ لازم | کاربرد در تصمیم |
|---|---|---|
| عملیات | خواندن یا هدف تغییر وضعیت | تأثیرات جانبی را ارزیابی کنید |
| پاسخ | وضعیت و معنی مستند‌شده | عملیات پشتیبانی‌شده را انتخاب کنید |
| نتیجه | تأیید شده یا مبهم | قبل از تکرار، تطبیق دهید |
| ارسال مجدد | سیاست مستند‌شده | تلاش‌ها و فشار را محدود کنید |
خانهٔ خالی در این کاربرگ، سؤال بی‌پاسخ است؛ آن را نتیجهٔ مثبت یا منفی فرض نکنید. مدرک موجود را از ادعا و فرض جدا نگه دارید.
یک مثال فرضی
فرض کنید درخواست ایجاد پس از دریافت توسط سرور با پایان مهلت پاسخ مواجه شود. تکرار کور می‌تواند رکورد دیگری ایجاد کند؛ ابتدا نتیجه را بررسی کنید.
نتیجهٔ مبهم را پیش از تلاش بعدی روشن کنید
نوع عملیات و معنای خطا را از قرارداد همان API بگیرید و سابقهٔ هر تلاش را بدون اطلاعات محرمانه ثبت کنید. در عملیات تغییردهنده، نتیجهٔ قبلی و پشتیبانی واقعی جلوگیری از اثر تکراری را بررسی کنید. این متن مقدار محدودیت، endpoint یا روش idempotency رهگارد را اعلام نمی‌کند.
مطالعهٔ تکمیلی: API ردیاب خودرو؛ چک‌لیست اتصال امن به ERP و CRM و رویداد تکراری در اتصال ردیاب؛ پردازش idempotent چه کمکی می‌کند؟.
برای بررسی دستگاه و مسیر رسمی خدمات، به رهگارد و فروشگاه ردیاب خودرو مراجعه کنید؛ امکانات و شرایط همان مدل را پیش از سفارش تأیید کنید.
هنوز دیدگاهی ثبت نشده. اولین نفر باشید!