استجابة 202 Accepted ليست دليلاً على التنفيذ

الخلاصة

• تعني 202 Accepted أن الطلب قُبل للمعالجة بينما لا تزال المعالجة غير مكتملة.
• قد تُرفض العملية أو تُلغى أو تنتهي صلاحيتها، وقد تفقد التفويض أو تنتهي من دون إحداث الأثر المقصود.
• يحتاج أي قرار يعتمد على الاكتمال إلى سجل إثبات للعملية غير المتزامنة يربط الطلب الأصلي بمرجع الحالة الرسمي وبالنتيجة النهائية.

لنتخيل وحدة تحكم بالتغييرات ترسل طلباً لتدوير سياسة وصول. تعيد الخدمة 202 Accepted مع رابط للعملية، فتسجّل الوحدة التغيير على أنه مكتمل، وتلغي بيانات الاعتماد القديمة وتحذف مواد الإدخال. بعد دقائق تصل العملية المنتظرة إلى عامل يعيد فحص السياسة ويرفضها. لقد قُبل الطلب، لكن التغيير لم يُنفّذ قط.

ليست المشكلة في رمز الحالة. المشكلة هي تحويل مرحلة واحدة من عملية موزعة إلى دليل على كل ما يليها.

تضع RFC 9110 معنى ضيقاً لـ 202 Accepted: قبل الخادم الطلب للمعالجة، لكن المعالجة لم تكتمل. قد يُنفذ الطلب لاحقاً وقد لا يُنفذ، إذ يمكن أن يُمنع عند بدء المعالجة الفعلية. فالاستجابة غير حاسمة عن قصد.

لهذا الحد أهمية لأن تبادل HTTP انتهى بالفعل. تشير RFC 9110 إلى أن HTTP لا يتيح إعادة إرسال رمز حالة العملية غير المتزامنة لاحقاً عبر التبادل المنتهي. وعندما يعدّ العميل أول 202 نجاحاً نهائياً، فإنه يفترض تتمة لم يقدمها البروتوكول.

ينبغي لتمثيل الاستجابة أن يصف الحالة الحالية وأن يشير إلى مراقب للحالة أو يضمّنه. لكن وجود رابط وحده لا يصنع إيصال اكتمال. يجب أن يكون المراقب مرجعاً موثوقاً للعملية نفسها، وأن يتاح ضمن السياق الأمني المقصود، وأن يبقى محفوظاً بالقدر اللازم لاتخاذ القرار، وأن يحدد الحالات النهائية بوضوح. لا تكفي صفحة عامة للطابور، أو نقطة «آخر مهمة» متغيرة، أو رابط ينتهي إلى 404 لاتخاذ قرار غير قابل للعكس.

تضيف RFC 7240 إشارة مرتبطة لكنها مختلفة. يستطيع العميل إرسال Prefer: respond-async للتعبير عن تفضيل المعالجة غير المتزامنة، ويمكن للخادم احترام ذلك بإرجاع 202. يختار التفضيل نمط التفاعل، لكنه لا يثبت أن العمل المؤجل نُفذ. وتترك المواصفة طريقة معرفة النتيجة النهائية لكل تطبيق.

أما Preference-Applied فنطاقه محدود أيضاً. وفق RFC 7240، يوضح الحقل تفضيلات الطلب التي احترمها الخادم. لذلك يمكنه تأكيد اختيار النمط غير المتزامن، لكنه لا يؤكد بدء العامل أو الكتابة أو الإشعار أو النشر أو أي أثر لاحق آخر.

يجب أن يفصل السجل التشغيلي بين ثلاثة أنواع من الحقائق على الأقل. أولها القبول: ما بايتات الطلب والهوية والهدف ومفتاح منع التكرار والاستجابة التي شوهدت، ومن أي نقطة. ثانيها التنفيذ: أي معرّف للعملية دخل أي طابور، وأي عامل استلمه، وما فحوص التفويض والاعتماديات التي كانت سارية، وهل تدخل الإلغاء أو انتهاء الصلاحية. ثالثها النتيجة: ما الآثار التي ثُبتت، وما الحالة النهائية التي أُعيدت، وهل ما زالت تلك الحالة موثوقة.

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

لا تجعل هذه الاحتمالات 202 معيباً. فقيمة القبول غير المتزامن أنه لا يفرض إبقاء الاتصال مفتوحاً طوال عملية طويلة. والانضباط الصحيح هو حفظ الاستجابة دليلاً على القبول، ثم طلب دليل لاحق لكل ادعاء لاحق.

الدليل العملي المطلوب هو سجل إثبات للعملية غير المتزامنة. يربط طريقة الطلب وهدفه وملخص جسمه بالهوية الموثقة، وحالة التفويض السارية في ذلك الوقت، ومفتاح منع التكرار، ونقطة الرصد، واستجابة 202، ومعرّف العملية، وعنوان مرجع الحالة الرسمي. ثم يسجل دخول الطابور، واستلام العامل للمهمة، وإعادة التحقق من التفويض والأنظمة التي تعتمد عليها العملية، وحالة الإلغاء، ومعرّفات الآثار، والنتيجة النهائية، ووقت الرصد، والقرار الذي استند إلى تلك النتيجة.

المصادر

RFC 9110 — HTTP Semantics, 202 Accepted؛ RFC 7240 — Prefer Header for HTTP.