افصل الاستلام عن اكتمال المعالجة
تعتمد الضمانات على المزود. توثق Stripe إمكان التكرار وعدم ضمان الترتيب. يجب أن يقابل نجاح HTTP استلاماً دائماً أو المعالجة المقصودة، لا مجرد وصول طلب إلى الذاكرة.
| الحالة | السلوك المتوقع | دليل مفيد |
|---|---|---|
| استلام الحدث نفسه مرتين | منع تكرار أثر العمل. | معرف معالج ونتيجة محفوظة. |
| وصول حدث قديم لاحقاً | عدم استبدال حالة أحدث عشوائياً. | حالة مرجعية وقاعدة انتقال. |
| معالجة ثقيلة | استلام دائم ثم عمل مؤجل. | حالة الطابور ونتيجة العامل. |
| تسليم مفقود | المطابقة والاسترداد وفق المزود. | فرق محدد وتصحيح متحقق منه. |
أنشئ استقبالاً قابلاً للتحقق
- افحص HTTPS والتوقيع والحماية من إعادة الإرسال وفق البروتوكول. تتحقق Stripe من التوقيع على الجسم الخام؛ قد يبطل تحويل JSON مسبقاً التحقق.
- احفظ الحدث أو معالجته بصورة دائمة قبل الإقرار المناسب. ميز معرف التسليم ومعرف الحدث ومفتاح منع تكرار أثر الإجراء.
- اختبر التكرار واختلال الترتيب وانقطاع العامل وإعادة تشغيله. اقرأ حالة الكائن المرجعية إذا لم يسمح حدث قديم بقرار آمن.
نظم الاسترداد والمطابقة
وثق المحاولات والمواعيد والأحداث غير المعالجة والمطابقة مع المزود. قد يخفي الإقرار السريع فشلاً لاحقاً. راقب أيضاً إجراء العمل النهائي وقلل الأسرار والبيانات الشخصية في السجلات.
المراجع الأساسية
التعامل الآمن مع طلبات الويب المتكررة.
قد يتكرر الإشعار بعد انتهاء المهلة أو فقدان الاستجابة. تعتمد الموثوقية على التحقق من المصدر، ومعرّف الحدث، والمعالجة التي تفصل الرسالة الجديدة عن الرسالة المكررة.
- التحقق من كل طلب باستخدام آلية المزوّد.
- اختبار إعادة المحاولات، والرسائل المكررة، وتغيير ترتيب الوصول.
- تأكيد الاستلام بشكل متسق بعد المعالجة أو التخزين الدائم.
المصدر الأساسي: IETF RFC 9457 — Problem Details for HTTP APIs. المنهج المرتبط: اقرأ الدليل العملي.