ما مفتاح العملية (idempotency)؟
مفتاح العملية يعني ألّا يتغيّر الناتج سواء أُرسل الطلب نفسه مرّة واحدة أو مرّات. فعند انتهاء المهلة الشبكية يعيد العميل إرسال الطلب؛ وإذا حسب الخادم هذه الإعادة عمليةً جديدة، نشأ طلب ثانٍ أو فاتورة ثانية أو دفعة ثانية. ولذلك يجب تعريف كيفية معالجة التكرار في كلّ طرف يُنشئ سجلًّا جديدًا.
كيف يُبنى مفتاح العملية عمليًا؟
- يولّد العميل مفتاح عملية فريدًا لكلّ عملية ويضيفه إلى الطلب. ويجب أن يبقى المفتاح نفسه حين يعيد المستخدم المحاولة.
- يحفظ الخادم المفتاح ونتيجة الطلب المرتبطة به.
- وحين يصل طلب ثانٍ بالمفتاح نفسه، لا يُفتح سجلّ جديد؛ بل تُعاد نتيجة العملية الأولى بالردّ نفسه.
- تُعرَّف مدّة حفظ المفاتيح (مثلًا عدد أيام محدَّد بحسب نوع العملية).
والنقطة الواجب الانتباه إليها: إذا كان المفتاح نفسه والمحتوى مختلفًا فهذا خطأ، ويجب رفضه برمز خطأ صريح؛ فإعادة النتيجة الأولى بصمت تُخفي تعارضًا حقيقيًا.
وفي جانب HTTP تُعدّ أساليب GET وPUT وDELETE محميّة من التكرار بحكم تعريفها؛ أمّا POST فلا. ولذلك يلزم مفتاح العملية أساسًا في أطراف POST.
أمان استدعاءات الرجوع (خطّاف الويب)
استدعاءات الإشعار الواردة من الخارج سطح هجوم، لأنّها تغيّر حالةً في نظامكم. وهذه خمسة إجراءات أساسية:
- التحقّق من التوقيع: ينبغي أن يرسل الطرف المُرسِل في الترويسة توقيعًا للمحتوى مولَّدًا بمفتاح سرّي مشترك؛ وعليكم إجراء الحساب نفسه والمقارنة.
- الطابع الزمني والحماية من إعادة التشغيل: طبّقوا نافذة زمنية ضيّقة لمنع إعادة تشغيل التواقيع القديمة، واحفظوا التواقيع المرئية مدّة قصيرة.
- التحقّق من المحتوى بصيغته الخام: يجب حساب التوقيع على المحتوى الخام قبل إعادة تسلسل JSON.
- لا تقبلوا الإشعار مصدرًا للحقيقة: فالإشعار ليس إلّا خبرًا بأنّ «شيئًا ما حدث». أمّا المبلغ والحالة والنتيجة فيجب التحقّق منها بقراءتها من جديد من واجهة API لدى المُرسِل.
- افصلوا الاستلام عن المعالجة: اقبلوا الاستدعاء بسرعة واكتبوه في الطابور، ثمّ نفّذوا منطق العمل انطلاقًا من الطابور. وبذلك لا تنشأ مهلة منتهية ولا إعادة إرسال لا لزوم لها لدى المُرسِل.
«مرّة واحدة بالضبط» وهم
لا يمكن في الأنظمة الموزّعة ضمان وصول الرسالة مرّة واحدة بالضبط. والهدف الواقعي هو وصول الرسالة مرّة واحدة على الأقلّ وإبطال المستقبِل أثرَ التكرار. ولذلك يجب إجراء فحص التكرار في جانب المستهلك أيضًا بمفتاح العملية أو معرّف الحدث.
سياسة الأخطاء وإعادة المحاولة
- في الأخطاء المؤقّتة (الشبكة، ورموز 5xx، وحدّ المعدّل) أعيدوا المحاولة بمدد انتظار متزايدة، وأضيفوا انحرافًا عشوائيًا إلى مدّة الانتظار.
- في الأخطاء الدائمة (خطأ التحقّق، وعدم التخويل) لا تعيدوا المحاولة؛ بل ضعوا السجلّ في طابور الأخطاء.
- احفظوا قيدًا لكلّ إعادة محاولة؛ فمن دون معرفة كم مرّة أُعيد كلّ طلب لا يمكن إجراء المطابقة.
القيم الواجب قياسها
تُتابَع سلامة التكامل بثلاثة أرقام: طول الطابور المنتظر، ومتوسّط تأخّر المعالجة، وعدد السجلّات التي تسقط في طابور الأخطاء. وتجدون مقابل هذه القياسات في المطابقة المالية في دليل التكامل البنكي. فإن لم تظهر هذه الثلاثة على اللوحة، بقي عمل التكامل قائمًا على الافتراض.
الأسئلة الشائعة
هل يمكن أن يولّد الخادم مفتاح العملية؟
يمكن، لكنّ الفائدة الحقيقية في توليد المفتاح لدى العميل. فإذا ولّده الخادم، لم يعرفه العميل في السيناريو الذي يضيع فيه الردّ، وصارت إعادة محاولته عمليةً جديدة.
هل يصحّ استخدام الاستعلام الدوري بدل خطّاف الويب؟
إذا كان الحجم منخفضًا وهناك تحمّل للتأخير، فالاستعلام الدوري أبسط وأكثر موثوقية. أمّا في الأحجام الكبيرة فيُنتج حملًا لا لزوم له؛ ويشيع عندئذٍ استخدام الأسلوبين معًا: خطّاف الويب للإشعار السريع، والاستعلام الدوري لتدارك الأحداث الفائتة.
ما أكثر سيناريو يُتخطّى في اختبار التكامل؟
السيناريو الذي يضيع فيه الردّ. فحالة «عُولج الطلب بنجاح لكنّ الردّ لم يصل إلى العميل» شائعة في الواقع، ولا يُعدّ مفتاح العملية محقَّقًا منه ما لم تُعَد هذه الحالة في الاختبار.