डुप्लिकेट API जमा: कुंजी जोड़ने से पहले idempotentता अनुबंध डिज़ाइन करें
कॉलर, पेलोड, परमाणु दावा और पुनर्च playback नीति को परिभाषित करें ताकि एक पुनः प्रयास का एक पूर्वनिर्धारित एप्लिकेशन परिणाम हो।
इस पृष्ठ पर
संक्षिप्त उत्तर
किसी पुनः प्रयासित ऑर्डर जमा करने के लिए, उसी प्रमाणित कॉलर और उसी तार्किक पेलोड के लिए कुंजी का पुनः उपयोग करें। एप्लिकेशन उस संयोजन को परमाणु रूप से दावा कर सकता है और पुनर्च playback के लिए अपना पूर्ण परिणाम बनाए रख सकता है। उसी कुंजी का उपयोग करके एक बदला हुआ पेलोड एक दस्तावेजीकृत एप्लिकेशन संघर्ष प्राप्त करेगा। एक अद्वितीय डेटाबेस पंक्ति दावों को समन्वयित करती है; यह अकेले यह गारंटी नहीं देती कि भुगतान, ईमेल या कोई अन्य बाह्य प्रभाव ठीक एक बार होता है।
HTTP अर्थव्यवस्था को एप्लिकेशन अनुबंध से अलग करें
एक idempotent ऑपरेशन का पुनः दोहराए जाने पर वही इच्छित सर्वर प्रभाव होता है जो एक बार किए जाने पर होता है। इस परिभाषा के लिए प्रतिक्रियाएं समान होनी आवश्यक नहीं हैं। एक POST अंत बिंदु केवल इसलिए नहीं कि क्लाइंट एक अतिरिक्त शीर्षक भेजता है, एक सुरक्षित पुनः प्रयास अनुबंध प्राप्त नहीं करता है। सर्वर को यह कार्यान्वित और दस्तावेजित करना आवश्यक है कि वह उस कुंजी की व्याख्या कैसे करता है, यह किन ऑपरेशनों को कवर करता है, और पुनः प्रयास प्रमाणीकरण और संग्रहीत अवस्था के साथ कैसे बातचीत करते हैं।
कुंजी को एक विश्वसनीय कॉलर तक सीमित करें
काल्पनिक उदाहरण में, कुंजी k1 एक प्रमाणित कॉलर और एक ऑर्डर-निर्माण ऑपरेशन की है। k1 का उपयोग करने वाला कोई अन्य कॉलर पहले कॉलर का परिणाम प्राप्त नहीं करना चाहिए। कॉलर पहचान को किसी स्वतंत्र रूप से प्रदान की गई पेलोड फ़ील्ड के बजाय विश्वसनीय प्रमाणीकरण से प्राप्त करें। यह परिभाषित करें कि क्या कुंजियां ऑपरेशनों पर एक नामस्थान साझा करती हैं या किसी विशिष्ट अंत बिंदु तक सीमित हैं, और उस सीमा को डेटाबेस एकतानता नियम में बनाए रखें।
पेलोड समानता को निर्दिष्ट करें
उसी कुंजी का उसी तार्किक जमा का प्रतिनिधित्व करना चाहिए। यह परिभाषित करें कि कौन से फ़ील्ड ऑपरेशन का हिस्सा हैं और एप्लिकेशन उनकी तुलना कैसे करता है, उदाहरण के लिए एक दस्तावेजीकृत नियम के अंतर्गत एक कैनोनिकल प्रतिनिधित्व या एक पचड़ का उपयोग करके। कच्चे JSON बाइट्स भिन्न हो सकते हैं जबकि वही डेटा दर्शाते हैं, इसलिए बाइट समानता एक नीति विकल्प है। इसके विपरीत, एक महत्वपूर्ण फ़ील्ड जैसे कि राशि को बाहर करने से गलती से भिन्न ऑर्डरों को समान पहचाना जा सकता है।
निर्मित पुनः प्रयास के माध्यम से चलें
मान लें कि कॉलर A कुंजी k1 के साथ एक पेलोड जमा करता है जो आइटम X की दो इकाइयों का अनुरोध करता है। पहला सफल अनुरोध एक ऑर्डर परिणाम संग्रहीत करता है। A द्वारा k1 और समतुल्य पेलोड के साथ एक पुनः प्रयास इस प्रस्तावित अनुबंध के अंतर्गत उस संग्रहीत परिणाम को लौटाता है। k1 का उपयोग करने वाला लेकिन तीन इकाइयों का अनुरोध करने वाला एक पेलोड असंगति के रूप में अस्वीकार कर दिया जाता है। यह एक डिज़ाइन उदाहरण है, यह दावा नहीं कि हर मौजूदा API वही स्थिति कोड या पुनर्च playback व्यवहार उपयोग करता है।
कुंजी को परमाणु रूप से दावा करें
एक जाँच-फिर-डालें अनुक्रम दौड़ सकता है: दो अनुरोध दोनों को कोई मौजूदा कुंजी नहीं दिख सकती। चुने हुए कॉलर, संचालन और कुंजी क्षेत्र पर एक डेटाबेस एकता बाधा एकल संग्रहीत दावा लागू कर सकती है। PostgreSQL INSERT ON CONFLICT डालें समन्वय में सहायता कर सकता है। अनुप्रयोग को अभी भी यह व्याख्या करने की आवश्यकता है कि क्या इसका एक नया दावा है या यह एक मौजूदा दावा पाता है, और हर हारने वाले अनुरोध को फिर भी संरक्षित संचालन न करने देना चाहिए।
प्रसंस्करण और पूर्ण स्थितियों का प्रतिनिधित्व करें
एक अनुरोध को वह अभी प्रसंस्करण में है जिससे अलग करने के लिए पर्याप्त स्थिति संग्रहीत करें जिसका परिणाम पुनः चलाया जा सकता है। एक समवर्ती पुनः प्रयास की प्रतिक्रिया कैसे होती है जबकि पहला प्रयास चल रहा है, इसे परिभाषित करें: प्रतीक्षा, एक दस्तावेज़ीकरण अस्थायी प्रतिक्रिया, या एक पुनः प्रयास निर्देश संभावित नीतियाँ हैं। जहाँ संभव हो, डेटाबेस परिवर्तनों के साथ पूर्ण स्थिति और उसका परिणाम सुसंगत रूप से बनाए रखें। किसी भी कुंजी पंक्ति की उपस्थिति को यह सबूत न मानें कि आदेश सफलतापूर्वक पूर्ण हो गया है।
बाहरी प्रभावों और क्रैश विंडो को संभालें
एक भुगतान प्रदाता या ईमेल सेवा स्वचालित रूप से डेटाबेस लेनदेन में भाग नहीं लेती। एक बाहरी प्रभाव के बाद लेकिन पूर्ण परिणाम संग्रहीत करने से पहले क्रैश एक पुनर्प्राप्ति समस्या बनाता है। एक टिकाऊ आउटबॉक्स, प्रदाता-समर्थित डुप्लिकेशन निवारण, या स्पष्ट पुनर्समन्वय एक समाधान का हिस्सा बन सकते हैं, प्रभाव पर निर्भर करते हुए। प्रत्येक की अपनी संविदा है। केवल स्थानीय कुंजी डालें को एक लेनदेन में लपेटना प्रणालियों में ठीक-एक बार व्यवहार स्थापित नहीं करता।
धारणा और पुनर्प्राप्ति सीमाओं को दस्तावेज़ करें
यह बताएं कि कुंजी और परिणाम कितने समय तक बनाए रखे जाते हैं, पुनः चलाने पर क्या लौटता है, और समाप्ति के बाद क्या होता है। एक रिकॉर्ड हटाने से एक बाद के अनुरोध को वही कुंजी के साथ एक नया जमा बनाने की अनुमति मिल सकती है। साथ ही त्यागे गए प्रसंस्करण स्थितियों के लिए पुनर्प्राप्ति और यह परिभाषित करें कि क्या विफल प्रयास पुनः उपयोग योग्य हैं। ये विकल्प सहीपन और भंडारण दोनों को प्रभावित करते हैं। एक क्लाइंट को एक सुरक्षित पुनः प्रयास को एक नई तार्किक संचालन बनाने से अलग करने में सक्षम होना चाहिए।
क्या जाँचें
- कुंजी का पुनः उपयोग केवल उसी तार्किक ऑपरेशन के लिए करें।
- खोज को प्रमाणित कॉलर तक सीमित करें।
- पेलोड समानता और असंगति व्यवहार को परिभाषित करें।
- दावा को परमाणु और अद्वितीय बनाएं।
- बाह्य प्रभावों और समाप्त कुंजियों के लिए पुनर्प्राप्ति की योजना बनाएं।
उपयोग की सीमाएँ
यह मार्गदर्शिका एक काल्पनिक एप्लिकेशन अनुबंध का वर्णन करती है, किसी पूर्ण सर्वर कार्यान्वयन या सार्वभौमिक Idempotency-Key मानक का नहीं। डेटाबेस एकतानता और HTTP idempotentता अकेले ठीक-एक बार बाह्य पार्श्व प्रभाव स्थापित नहीं करते हैं।