Async APIs: The 202 Accepted + Polling Pattern for Long-Running Operations
خیلی از APIها مثل تولید گزارش یا پردازش ویدیو در یک پاسخ ساده جا نمیگیرند و به Timeout میخورند. الگوی 202 Accepted این مشکل را حل کرده: سرور کار را میپذیرد، یک کد رهگیری برمیگرداند و کلاینت بعداً نتیجه را از سرور درخواست میکند. هدرهای Location و Retry-After این فرآیند را استاندارد و مطمئن میسازند.
چرا مهمه؟
چه چیزی تغییر کرده؟ صنعت API به این نتیجه رسیده که عملیات طولانی نباید در یک Response معمولی HTTP جا بگیرد. چه کسانی تحت تأثیر قرار گرفتهاند؟ تمام توسعهدهندگان بکاند، تیمهای DevOps و معماران نرمافزار که محصولشان نیاز به پردازش ناهمزمان دارد. چرا خواننده باید اهمیت بدهد؟ اگر API شما گزارشهای حجیم یا پردازش فایل دارد و از این الگو استفاده نمیکند، کاربران شما دائماً خطای قطع ارتباط میبینند و اعتمادشان را از دست میدهید. این الگو، استاندارد طلایی وب مدرن است.
به درد کی میخوره؟
• توسعهدهندگان بکاند • معماران نرمافزار و سیستم • تیمهای DevOps • مدیران فنی و Technical Leads
تو عمل چی کار کنیم؟
خواننده با این خبر میتواند معماری API خود را برای عملیات طولانی بهینه کند. دیگر کاربر مجبور نیست تا ثانیهها منتظر بماند و مرورگرش قطع شود. با پیادهسازی هدر Retry-After و کد وضعیت 202، یک API حرفهای و مقاوم میسازید که در برابر بار بالا هم پایدار میماند. نتیجه نهایی کاهش خطا، رضایت بیشتر کاربر و یکپارچگی بهتر سیستم است.
نظر BlueIT News
بسیاری از توسعهدهندگان تازهکار، کد وضعیت ۲۰۲ را اشتباه میگیرند و آن را به معنای انجام شدن کار تفسیر میکنند، در حالی که فقط یعنی «کار را قبول کردم». هشدار BlueIT: حتماً در کنار Polling، مکانیزم Webhook را هم ارائه دهید تا کلاینتهای حرفهای مجبور به سوالکشی بیمورد نشوند.