اختيار إجراء الاسترداد المناسب
يصف رمز الخطأ نفسه حالتين مختلفتين. تحقق منretryable قبل
اتخاذ أي إجراء؛ فحالة HTTP وحدها لا تحدد ما إذا كان ينبغي إعادة المحاولة.
مدخلات مختلفة
الطلب ما يزال قيد المعالجة
يتضمن هذا المثال أيضًا ترويسة استجابة HTTP التالية:Retry-After: 1.
الحفاظ على ثبات هوية إعادة المحاولة
بالنسبة إلى العمليات التي يوثَّق فيها دعم idempotency، يقتصر نطاق المفتاح على المؤسسة وحساب الخدمة وطريقة HTTP ومسار المورد وإصدار API الذي تم تحديده. وتغيير أي عنصر من هذه العناصر ينشئ هوية مختلفة لإعادة المحاولة؛ ولا يؤدي إلى استرداد العملية الأصلية. ولا يؤدي تدوير بيانات اعتماد ضمن حساب الخدمة نفسه إلى تغيير هذه الهوية، مع أنه يجب أن تملك بيانات الاعتماد البديلة الصلاحيات اللازمة. احتفظ بالمفتاح والمحتوى والمسار والإصدار الأصلية عند الاسترداد بعد انتهاء المهلة. لا تنشئ مفتاحًا جديدًا لمجرد تجاوز التعارض؛ فقد تكون عملية الكتابة الأصلية قد نجحت بالفعل. استرجع المورد عندما يكون معرّفه معروفًا، واتبع إجراء الاسترداد الموثّق للعملية. وتتضمن الاستجابة المعاد تشغيلها بعد اكتمال العمليةIdempotent-Replayed: true عندما توثّق العملية إعادة تشغيل الاستجابة.
إن إرسال Idempotency-Key لا يجعل العملية idempotent ما لم يذكر
مرجعها صراحةً أنها تدعم هذه الترويسة. والحماية من إعادة المحاولة محدودة بسياسة الاحتفاظ
الخاصة بالعملية؛ وليست ضمانًا دائمًا ضد التكرار.
إذا بقيت المعالجة دون حل، فتواصل مع دعم Living Security
وزوّدهم بـ request_id والطابع الزمني بتوقيت UTC والطريقة والمسار وإصدار API. لا تُدرج أبدًا
مفتاح API أو سر العميل أو رمز الوصول.