8 تغريدة 37 قراءة Mar 22, 2023
تخيل معايا عندك user جه يطلب order و ليكن سعره 1000$ فجأه لقي نفسه طالبه 3 مرات بدل مرة واحدة و اتعور في 2000$ زيادة، تخيلت؟ 🫣
كده يا معلم انت موقع concept مهم اسمه Idempotent API و هتشمت فينا رجاله الـFrontend و الـMobile😂
1/n 🧵
طيب ده حصل ازاي؟ في العادي الـUser بيدخل ال App يعمل ال order ال App بيبعت HTTP POST request للـServer و هنا بيحصل خطوتين مهمين (الاولي) الServer بيرد بـStatus code 201 بعد الـorder ما يتم، (التانية) الApp بيظهر Message للـUser يقوله الـorder تم.
طيب امال فين المشكلة؟
2/n
المشكلة بتظهر لما يطلع خازوق بين الخطوه (الاولي) و (التانية) زي Network Failure مثلا. ساعتها الOrder بيكون تم و الفلوس اتخصمت بس الApp موصلهوش الرد بتاع الـServer فا بيقوم مطلع للـUser زرار الـRetry يقوم الـUser بمنتهي البرأة دايس عليه فا يطلب نفس الـorder مره كمان وهكذا...
3/n
عرفنا المشكلة؟ تعالي بقي نرجع تاني للمصطلح اللي قولنا عليه في الاول الـIdempotent API ده معناه ان لازم لما الـUser يبعت ((نفس الـrequest بالظبط)) اكتر مرة لازم يكون تأثيرهم كأن بالظبط الـrequest اتبعتت مرة واحدة فقط.
طيب نعمل ده ازاي و هو الHTTP اصلا stateless؟
4/n
الـstateless بختصار ان كلrequest متعرفش حاجة عن اللي قبلها و مش هتقدر تحدد اذا كان نفس الUser طلب نفس الـOrder ولا لأ.
خد بالك احنا عندنا HTTP methods هما اصلا idempotent by default زي الـGET, PUT, DELETE بمعني ان عمرهم ما بيغيروا الـstate بتاع الresource و دول مفيش خوف منهم.
5/n
اللي تخاف منها هي الـHTTP POST method.
ممكن تحل ده عن طريق ان كل POST request يتبعت معاها header اسمه x-idempotence-key شايل unique identifier من الـclient زي الـuuid مثلا،
و كل ما order request تتم هتتحط في الـCache مع الـResponse بتاعها عن طريق الـuuid اللي جاي في الـheader
6/n
و كده بسهوله كل ما الـserver يجيله order همسك ال x-idempotence-key اللي جيله يبص عليه فالـCache لو موجود هيرفضه و يرد بـ status code 304 (Not Modified) عشان يعرف الClient ان ده نفس الOrder اللي اتعمل من شوية و بكده الكل يكون مبسوط
7/n
دي اول مره اشرح فيها حاجة Public و احتمال اعملها تاني عشان لو عندي معلومة غلط حد يصلحهالي او يزودني بحاجة مكنتش اعرفها.
8/n

جاري تحميل الاقتراحات...