يطلب موظف تصدير تقرير كبير، فيرد API برمز 202 وتظهر رسالة «تم التصدير». بعد دقائق لا يجد الملف ولا يعرف هل يعيد الطلب. المشكلة أن الواجهة أعلنت نتيجة لم تثبت بعد. يحتاج مسار العمل غير المتزامن فرقًا واضحًا بين قبول الطلب، واستمرار التنفيذ، وتوافر الناتج للمستخدم الصحيح.
اجعل معنى الاستجابة دقيقًا
توضح مواصفة HTTP لرمز 202 أن الطلب قُبل للمعالجة لكن المعالجة لم تكتمل، وقد لا ينفذ لاحقًا. وتوصي بأن يوضح المحتوى الحالة الحالية ويشير إلى وسيلة متابعتها. لا تجعل الرمز وحده دليلًا على إنشاء ملف أو اعتماد عملية تجارية.
اقترح رسالة «قُبل طلب التقرير» مع معرف مهمة محفوظ. اتفق مع فريق المنتج على حالات مفهومة مثل انتظار وتنفيذ ونجاح وفشل، دون تقديم هذه الأسماء باعتبارها حالات مفروضة في HTTP. عند النجاح اربط النتيجة بالمهمة نفسها، وافحص صلاحية فتحها من الخادم.
اختبر دورة المهمة بعينة مصطنعة
- أرسل طلب تقرير تجريبي وسجل معرف المهمة المعاد.
- افتح شاشة المتابعة قبل اكتمال المعالجة؛ يجب ألا تعرض رابط نجاح وهميًا.
- حدّث الصفحة ثم عد من شاشة أخرى، وتأكد من استمرار متابعة المعرف نفسه.
- بعد اكتمال المهمة افتح الملف وافحص أنه يطابق نطاق الطلب والحساب.
سجل وقت كل خطوة والحالة الفعلية. هذه تجربة مقترحة وليست قياسًا لأداء خدمة بعينها. إذا تغير معرف المهمة بعد إعادة فتح الشاشة، فقد تخفي الواجهة الطلب الأول وتدفع الموظف لإنشاء طلبات إضافية دون قصد.
اتفق على الفشل وانتهاء المتابعة
جهز مهمة تفشل عمدًا في بيئة الاختبار، ومهمة تتأخر. ما الرسالة؟ ومن يملك إعادة المحاولة؟ افصل فشل قراءة الحالة بسبب الشبكة عن فشل تنفيذ التقرير نفسه. انقطاع المتصفح لا يثبت توقف المعالجة، وانتهاء مهلة الواجهة لا يسمح تلقائيًا بإعادة إجراء قد يكرر أثرًا تجاريًا.
سلّم دليلًا يمكن مراجعته
ضمن تطوير بوابة الويب اطلب من الفحص التقني تسجيل الطلب الأول وتسلسل الحالات والنتيجة النهائية. معيار القبول أن يعرف المستخدم ما الذي قُبل وما الذي اكتمل، ويستطيع الرجوع للمهمة دون تخمين أو تكرار غير مقصود.
