SkillByAIइंटरैक्टिव संस्करण खोलें →

पाठ 20 / 25

आइडेम्पोटेंसी

Idempotent methods और Idempotency-Key headers से retries को सुरक्षित बनाएँ, खासकर payment जैसे operations में।

जितनी बार भी, वही नतीजा

एक ऑपरेशन आइडेम्पोटेंट है अगर उसे एक बार बुलाना और कई बार बुलाना एक ही असर डाले। PUT /orders/482 (इसी बॉडी से बदलना) और DELETE /orders/482 आइडेम्पोटेंट हैं — रिसोर्स दोनों तरह से एक ही स्थिति में पहुँचता है।

रिट्राई के लिए यह क्यों मायने रखता है

नेटवर्क अक्सर रिस्पॉन्स गिराते हैं, हमेशा रिक्वेस्ट नहीं — जिस क्लाइंट का टाइमआउट हो जाए, उसे नहीं पता कि सर्वर ने असल में इसे प्रोसेस किया या नहीं। यदि ऑपरेशन आइडेम्पोटेंट है, तो रिट्राई करना हमेशा सुरक्षित है। POST (आमतौर पर बनाता है) क्लासिक गैर-आइडेम्पोटेंट मामला है।

POST को रिट्राई के लिए सुरक्षित बनाना

एक Idempotency-Key हेडर क्लाइंट को प्रति तार्किक ऑपरेशन एक अद्वितीय id देने देता है; सर्वर नतीजा स्टोर करता है और वही की दोबारा आने पर उसे वापस भेज देता है — भुगतान API में आम।

POST /payments HTTP/1.1
Idempotency-Key: 6c9a1e4e-3f21
Content-Type: application/json

{ "amount": 500, "currency": "INR" }

PATCH आमतौर पर आइडेम्पोटेंट नहीं होता

{ "increment": 1 } जैसा PATCH हर बार लागू होने पर अलग नतीजा देता है। जब आइडेम्पोटेंसी मायने रखे, तो ऐसे PATCH बॉडी पसंद करें जो पूर्ण मान सेट करें।