تكرار الطلبات عند العمل مع API: الأسباب والحماية

لماذا يظهر التكرار بعد إجراء واحد

قد يضغط مالك اللوحة على الزر مرة واحدة ويرى عدة طلبات متطابقة: للمتابعين أو المشاهدات أو التفاعلات أو خدمة أخرى. عادةً لا تكمن المشكلة في النقرة نفسها، بل في السلسلة بين العميل وAPI وقاعدة البيانات والمورّد.

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

المهلة لا تعني أن الطلب لم يُنشأ

السبب الأكثر شيوعًا هو انتظار العميل للرد لفترة محدودة. يستقبل الخادم الطلب وينشئ الطلب، لكنه يرد بعد انتهاء المهلة المحددة. يعتبر العميل العملية فاشلة ويعيد إرسالها.

نتيجة لذلك، يكون الطلب الأول موجودًا بالفعل في قاعدة البيانات، ويُنشئ الطلب الثاني طلبًا آخر. يحدث هذا كثيرًا بشكل خاص عند بطء رد API الخارجي أو ازدحام قائمة الانتظار أو عدم استقرار الاتصال بين الخدمات.

المهلة تدل فقط على غياب الرد، وليس على غياب معالجة الطلب.

الإعادات التلقائية على جانب العميل

غالبًا ما تعيد مكتبات طلبات HTTP والمهام الخلفية وخدمات التكامل إرسال الطلب تلقائيًا. قد يكون السبب خطأ في الاتصال أو رمز رد من الخادم أو انقطاع الشبكة أو ردًا طويلًا جدًا.

الإعادة بحد ذاتها مفيدة: فهي تقلل عدد الطلبات المفقودة عند الأعطال المؤقتة. عيب هذا النهج أنه بدون حماية من إعادة المعالجة يحوّل أي عدم استقرار في الشبكة إلى تكرار.

• قد تُطلق الإعادة في كود الموقع أو البوت؛
• قد تعيد قائمة الانتظار تشغيل المهمة؛
• قد يعيد الوسيط أو وحدة التكامل إرسال الطلب؛
• قد يعيد المشغّل إرسال الطلب يدويًا بعد خطأ.

الطلب المتكرر يصل قبل الرد الأول

أحيانًا يصل طلبان متطابقان فعليًا إلى API في وقت واحد تقريبًا. مثلًا، أرسل المستخدم النموذج مرتين، أو لم تعطّل الواجهة الأمامية الزر، أو بدأت المهمة الخلفية من جديد قبل انتهاء الأولى.

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

تُسمى هذه الحالة تسابق البيانات. التحقق المسبق البسيط في الكود لا يحمي منها بالكامل. عيب التحقق دون قيد على مستوى قاعدة البيانات أنه ينهار تحت الحمل المتوازي.

حُفظ الطلب لكن ضاع رد API

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

لا يعرف العميل هل قُبل الطلب أم لا، فيعيد العملية. يتعامل API دون آلية تحقق منفصلة مع الطلب كأنه جديد. في السجل، يبدو الأمر غالبًا وكأن الخدمة أنشأت طلبين «بنفسها»، رغم وصول طلبين إليها.

مفتاح الثبات لإنشاء الطلب

تحتاج عمليات الإنشاء إلى مفتاح ثبات فريد. يولّده العميل قبل الإرسال الأول ويرسله مع معاملات الطلب. عند الإعادة بسبب مهلة أو خطأ يُستخدم المفتاح نفسه.

يحفظ API المفتاح مع نتيجة المعالجة. إذا وصل طلب بمفتاح معروف مسبقًا، لا ينشئ الخادم طلبًا جديدًا، بل يعيد نتيجة الطلب الأول: معرّف الطلب أو حالته أو الخطأ الذي تشكّل سابقًا.

يجب أن يقابل المفتاح الواحد عملية تجارية واحدة، لا اتصال HTTP واحد.

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

يجب أن تتحكم قاعدة البيانات في التفرد

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

يجب أن ترفض قاعدة البيانات السجل الثاني، حتى لو وصل معالجان إلى الإنشاء في الوقت نفسه. بعد التعارض، يعيد API الطلب الموجود، لا خطأً بلا توضيح.

عيب قيد التفرد الصارم أنه لا يمكن بناؤه على الرابط أو اسم المستخدم فقط. قد يطلب العميل بوعي خدمة واحدة على القناة نفسها عدة مرات. القيد الواسع جدًا سيمنع عمليات الشراء المتكررة الطبيعية.

قد تُسلّم قائمة الانتظار المهمة أكثر من مرة

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

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

عيب تعطيل التسليم المتكرر أن بعض الطلبات قد تضيع عند سقوط العامل. الأكثر أمانًا هو قبول الإعادات المحتملة وجعل المعالج مقاومًا لها.

ينشأ التكرار بين اللوحة والمورّد

قد يُنشأ الطلب الداخلي مرة واحدة، لكن يُرسل الطلب إلى API الخارجي مرتين. السبب نفسه: لم تتلقَّ اللوحة ردًا من المورّد فقررت إعادة الإرسال. إذا كان المورّد قد قبل الطلب الأول، فستظهر لديه طلبات متطابقة.

يلزم ربط منفصل للطلب الداخلي بالخارجي: معرّف الإرسال أو مفتاح الثبات أو رد المورّد المحفوظ. لا يمكن افتراض أن الحماية عند مدخل اللوحة الخاصة ستحمي الاستدعاءات الصادرة تلقائيًا.

عيب المطابقة مع API خارجي أن ليس كل مورّد يدعم البحث بالمفتاح الخارجي. حينها يجب تسجيل محاولات الإرسال وتحليل الحالات غير المحددة بشكل منفصل.

يجب ألا ينشئ خطاف الويب طلبًا جديدًا

تُبلغ خطافات الويب عن التغييرات: قُبل الطلب، أو بدأ، أو اكتمل، أو أُلغي، أو يحتاج إلى تحقق. يظهر الخطأ عندما يعتبر معالج خطاف الويب الإشعار أمرًا بإنشاء الطلب من جديد.

قد يصل خطاف الويب نفسه مرة أخرى. يعيد المرسل التسليم إذا لم يتلقَّ تأكيدًا، وأحيانًا تصل الإشعارات بترتيب مختلف. يجب أن يجد المعالج الطلب الموجود بالمعرّف الخارجي ويحدّث الحالة.

عيب معالجة خطافات الويب حسب وقت الاستلام فقط أن إشعارًا متأخرًا قد يستبدل الحالة الفعلية بحالة قديمة. يلزم معرّف حدث أو إصدار حالة أو قواعد انتقال واضحة.

أي السجلات تساعد في إيجاد مصدر التكرار

للتحقيق لا يكفي رؤية رقمَي طلب فقط. يلزم بيانات عن كل مرحلة من المعالجة: وقت الطلب، ومفتاح الثبات، ومعرّف العميل، ومعاملات الطلب، ورقم المهمة الخلفية، ورد API الخارجي، ومحاولات الإعادة.

• طابق التكرار بمفتاح العملية، لا بالرابط فقط؛
• تحقق مما إذا كانت هناك طلبات متطابقة في سجل API الوارد؛
• انظر هل تكررت المهمة في قائمة الانتظار؛
• افصل إنشاء الطلب الداخلي عن الإرسال إلى المورّد؛
• احفظ المعرّف الخارجي للطلب فور تلقي الرد.

عيب السجلات القصيرة جدًا أن مصدر المشكلة يختفي قبل تحليله. عيب التسجيل المفرط أن السجل قد يحتوي على رموز وبيانات شخصية وحقول حساسة أخرى، لذا يجب إخفاؤها.

كيف تتعامل مع نتيجة طلب غير محددة

بعد المهلة لا يمكن إنشاء الطلب فورًا من جديد ببيانات جديدة. يجب أن يتحقق API أولًا من العملية بمفتاح الثبات أو معرّف العميل. إذا وُجد الطلب، تُعاد حالته الحالية. وإذا كانت المعالجة ما زالت جارية، يتلقى العميل حالة انتظار.

1. أنشئ مفتاح العملية قبل الطلب الأول.
2. أرسل المفتاح نفسه عند كل إعادة.
3. احفظ المفتاح والطلب في عملية قاعدة بيانات محمية واحدة.
4. مرّر معرّف العملية إلى قائمة الانتظار وAPI الخارجي.
5. أعد الطلب المنشأ سابقًا عند الطلب المتكرر.

يتطلب هذا السيناريو تطوير API وتكامل العميل. عيبه أن التصحيح أصعب والحالات أكثر، لكن التسليم المتكرر للطلب يتوقف عن كونه يعني تلقائيًا عملية شراء متكررة.