ما هو الـ Idempotency؟
Idempotency هو خاصية بتضمن إنه لو بعت نفس الـ API Request أكثر من مرة، النتيجة النهائية ما تتغيرش، كأنك نفذته مرة واحدة فقط.
تخيّلي السيناريو:
واحدة بتحجز موعد عند طبيب من خلال تطبيق إلكتروني.
ضغطت على زر “احجز الآن” ➜ لكن النت قطع قبل ما يوصل الرد من السيرفر.
فكّرت إن العملية فشلت ➜ رجعت وضغطت “احجز الآن” مرة تانية
💥 بدون Idempotency:
- السيرفر استقبل الطلب مرتين.
- اتسجل موعدين لنفس الشخص في نفس اليوم.
- الدكتور نفسه مش هيعرف يعالج المريض مرتين.
- وبتبدأ مشاكل في الجدولة، وDouble Booking.
طيب، الحل؟
➤ نستخدم Idempotency Key:
في كل مرة المستخدم يضغط “احجز”، التطبيق يولّد مفتاح (UUID مثلاً):
POST /appointments
Idempotency-Key: abc123xyz
Body:
{
“patient_id”: 88,
“doctor_id”: 12,
“date”: “2025-08-03T11:00:00”
}
➤ السيرفر يشوف الـ Key:
- هل استقبلت طلب بهذا المفتاح من قبل؟ ✅
- لو نعم: يرجّع نفس الموعد بدون تنفيذ جديد.
- لو لأ: يسجل الموعد ويخزن الـ Key معاه في قاعدة البيانات
والنتيجة؟
- المستخدم ضغط مرتين ➜ لكن حُجز موعد واحد فقط.
- التطبيق صار ذكي ويتعامل مع حالات الشبكة الضعيفة.
- تجربة المستخدم أصبحت أكثر احترافية وموثوقة.
- ما فيش تضارب في جدول المواعيد.
🎯 ليه المثال ده مهم في الاختبار؟
لأن ده موقف بيتكرر يوميًا:
- المستخدم مش دايمًا يعرف لو الضغط نجح ولا لأ.
- أي ضغط مكرر ممكن يعمل ضرر كبير لو السيرفر مش “Idempotent”.
ازاي تختبري ده في الـ API Testing؟
- ابعتي نفس الـ POST مرتين بنفس الـ
Idempotency-Key. - راقبي إن السيرفر:
- ما يسجلش إلا موعد واحد.
- يرجّع نفس الاستجابة في المرتين.
- ابعتي مرة تالتة بمفتاح مختلف ➜ لازم يسجل موعد جديد
يجب أنت تكون مسجل الدخول لتضيف تعليقاً.