एक आइडेम्पोटेंट अनुरोध क्या है?
स्क्रैपेलेस स्क्रैपिंग एपीआई संरचित वेब-डेटा कार्यों के लिए प्रमाणित HTTP अनुरोधों को स्वीकार करता है और दस्तावेजित प्रतिक्रिया अवस्थाओं के माध्यम से अनुरोध परिणामों का प्रदर्शन करता है।
संक्षेप में
- एक आइडेम्पोटेंट अनुरोध का सर्वर स्थिति पर एक ही इच्छित प्रभाव होता है चाहे वही अनुरोध एक बार या कई बार लागू किया जाए। HTTP GET, HEAD, OPTIONS, TRACE, PUT, और DELETE को विधि अभिसंकेर द्वारा आइडेम्पोटेंट के रूप में परिभाषित करता है।
- ऑपरेशन पहचान को परिभाषित करें। क्लाइंट एक तार्किक क्रिया के लिए एक स्थिर पहचानकर्ता बनाता है। पहचानकर्ता को उस क्रिया की दोहराई गई डिलीवरी के लिए वही रहना चाहिए और एक सच में नई क्रिया के लिए इसे बदलना चाहिए। कॉलर्स के बीच टकराव को रोकने के लिए इसे टेनेट या खाता द्वारा स्कोप करें।
- परिणाम और पहचान को एक साथ समर्पित करें। व्यापार परिवर्तन और आइडेम्पोटेंसी रिकॉर्ड को एक लेन-देन की सीमा या समकक्ष स्थिरता डिजाइन की आवश्यकता होती है। परिवर्तन से पहले कुंजी को रिकॉर्ड करना उस कार्य को दबा सकता है जो कभी पूरा नहीं हुआ; परिवर्तन के बाद केवल इसे रिकॉर्ड करना डुप्लिकेट निष्पादन के लिए एक खिड़की छोड़ देता है।
- उस तार्किक क्रिया को चुनें जो एक पहचान प्राप्त करती है और जब क्लाइंट को नई बनानी चाहिए उसका दस्तावेज करें। एक डुप्लिकेट परिणाम अक्सर डेटा-मॉडल समस्या होती है न कि HTTP-लाइब्रेरी समस्या।
- एक आइडेम्पोटेंट अनुरोध एक संकुचित सर्वर स्थिति द्वारा परिभाषित है: एक आवेदन और कई समान अनुप्रयोगों का वही इच्छित प्रभाव होता है।
परिभाषा और संक्षिप्त उत्तर
एक आइडेम्पोटेंट अनुरोध का सर्वर स्थिति पर एक ही इच्छित प्रभाव होता है चाहे वही अनुरोध एक बार या कई बार लागू किया जाए। परिभाषा अनुरोधित स्थिति संक्रमण से संबंधित है, न कि समान प्रतिक्रिया निकायों, समान स्थिति कोडों, या साइड इफेक्ट्स की अनुपस्थिति से। एक सर्वर हर कॉल को लॉग कर सकता है, मेट्रिक्स को अपडेट कर सकता है, और विभिन्न मेटाडेटा को वापस कर सकता है जबकि फिर भी समान संसाधन प्रभाव को बनाए रखता है। महत्वपूर्ण यह है कि डुप्लिकेट डिलीवरी पहले सफल अनुप्रयोग के प्रभाव के अलावा अतिरिक्त संसाधन परिवर्तन नहीं करती है।
HTTP GET, HEAD, OPTIONS, TRACE, PUT, और DELETE को विधि अभिसंकेर द्वारा आइडेम्पोटेंट के रूप में परिभाषित करता है। सुरक्षित विधियाँ आइडेम्पोटेंट होती हैं क्योंकि क्लाइंट स्थिति परिवर्तन के लिए नहीं पूछ रहा है। PUT आइडेम्पोटेंट है क्योंकि वही पूरा प्रतिनिधित्व को उसी लक्ष्यों पर भेजने से वह लक्ष्य उसी अनुरोधित स्थिति में रहता है। DELETE आइडेम्पोटेंट है क्योंकि लक्ष्य पहले सफल डिलीट के बाद हटा रहता है, भले ही एक बाद की प्रतिक्रिया यह रिपोर्ट करे कि संसाधन अब मौजूद नहीं है। POST और PATCH डिफ़ॉल्ट रूप से आइडेम्पोटेंट नहीं होते हैं क्योंकि पुनरावृत्ति आवेदन परिवर्तन पैदा कर सकती है या जमा कर सकती है।
आइडेम्पोटेंसी महत्वपूर्ण होती है जब वितरित प्रणालियाँ नहीं जानतीं कि कोई ऑपरेशन पूरा हुआ या नहीं। एक क्लाइंट एक अनुरोध भेज सकता है, सर्वर परिवर्तन को कमिट कर सकता है, और प्रतिक्रिया को खो सकता है इससे पहले कि क्लाइंट इसे पढ़े। यदि ऑपरेशन की एक स्थिर पहचान है, तो सर्वर एक डुप्लिकेट प्रस्तुतिकरण को पहचान सकता है और रिकॉर्डेड परिणाम को वापस कर सकता है बजाय इसके कि व्यवसाय क्रिया को फिर से लागू करे। भुगतान निर्माण, नौकरी प्रस्तुति, वेबहुक खपत, इन्वेंटरी आरक्षण, और संदेश प्रसंस्करण सभी को यह सुरक्षा की आवश्यकता होती है जब डुप्लिकेट डिलीवरी संभव हो।
विधि नाम अकेले ही पर्याप्त नहीं है। एक GET के रूप में कार्यान्वित एक अंत बिंदु जो एक काउंटर को बढ़ाता है वह विधि अभिसंकेर का उल्लंघन करता है, जबकि एक POST अंत बिंदु अनुप्रयोग स्तर की आइडेम्पोटेंसी को एक अनोखी ऑपरेशन कुंजी और सहेजे गए परिणाम के माध्यम से प्रदान कर सकता है। एपीआई दस्तावेज़ों को पहचान क्षेत्र, संरक्षण अवधि, संघर्ष नियम, और प्रतिक्रिया व्यवहार को निर्दिष्ट करना चाहिए। क्लाइंट को यह मानने की आवश्यकता नहीं होनी चाहिए कि हर सेवा किसी कस्टम आइडेम्पोटेंसी हेडर को समान तरीके से व्याख्या करती है।
एक एपीआई में आइडेम्पोटेंसी कैसे काम करती है
- ऑपरेशन पहचान को परिभाषित करें। क्लाइंट एक तार्किक क्रिया के लिए एक स्थिर पहचानकर्ता बनाता है। पहचानकर्ता को उस क्रिया की दोहराई गई डिलीवरी के लिए वही रहना चाहिए और एक सच में नई क्रिया के लिए इसे बदलना चाहिए। कॉलर्स के बीच टकराव को रोकने के लिए इसे टेनेट या खाता द्वारा स्कोप करें।
- पहचान को डेटा के साथ बांधें। सर्वर संबंधित अनुरोध क्षेत्रों का एक डाइजेस्ट या मानकीकृत प्रतिनिधित्व रिकॉर्ड करता है। यदि वही कुंजी विभिन्न इनपुट के साथ आती है, तो सर्वर को टकराव को अस्वीकार करना चाहिए बजाय इसके कि वह संबंधित क्रिया के लिए चुपचाप परिणाम लौटाए।
- परिणाम और पहचान को एक साथ समर्पित करें। व्यापार परिवर्तन और आइडेम्पोटेंसी रिकॉर्ड को एक लेन-देन की सीमा या समकक्ष स्थिरता डिजाइन की आवश्यकता होती है। परिवर्तन से पहले कुंजी को रिकॉर्ड करना उस कार्य को दबा सकता है जो कभी पूरा नहीं हुआ; परिवर्तन के बाद केवल इसे रिकॉर्ड करना डुप्लिकेट निष्पादन के लिए एक खिड़की छोड़ देता है।
- एक स्थिर परिणाम लौटाएँ। एक पुनरावृत्त डिलीवरी सहेजे गए संसाधन पहचानकर्ता, स्थिति, और प्रतिक्रिया डेटा लौटा सकती है। परिवहन स्थिति कुछ डिज़ाइन में भिन्न हो सकती है, लेकिन क्लाइंट को यह एक दस्तावेजित संकेत होना चाहिए कि वही तार्किक क्रिया पहचानी गई थी बजाय इसके कि फिर से लागू की गई हो।
वास्तविक प्रणालियों में आइडेम्पोटेंट अनुरोध
सृजन ऑपरेशन
एक सृजन अंत बिंदु दो आदेश, नौकरियों, या चार्ज को रोक सकता है जब एक तार्किक क्रिया सेवा को एक से अधिक बार पहुंचती है।
वेबहुक उपभोक्ता
एक उपभोक्ता प्रदाता इवेंट पहचानकर्ता को संग्रहीत कर सकता है और व्यापार परत पर प्रत्येक इवेंट को एक बार संसाधित कर सकता है भले ही डिलीवरी एक से अधिक बार होती है।
क्यू श्रमिक
एक श्रमिक संदेश पहचानकर्ता या डोमेन कमांड पहचानकर्ता का उपयोग करते हुए दोहराई गई डिलीवरी को स्थिति संक्रमण को डुप्लिकेट करने से रोक सकता है।
इन्फ्रास्ट्रक्चर एपीआई
प्रावधान कॉल एक नामित संसाधन को एक वांछित कॉन्फ़िगरेशन की ओर एकत्रित कर सकते हैं बजाय इसके कि हर अनुरोध पर एक नया संसाधन बनाए।
HTTP विधियाँ और आइडेम्पोटेंट इरादा
साइड-बाय-साइड दृश्य समीपस्थ अवधारणाओं को आपस में विनिमेय के रूप में व्यवहार करने से रोकता है। ग्राहक या सर्वर व्यवहार बदलने से पहले सक्रिय अनुबंध की पहचान करने के लिए तुलना का उपयोग करें।
| धारणा या संकेत | अर्थ | परिचालन नोट |
|---|---|---|
| GET | हाँ | राज्य परिवर्तन का अनुरोध किए बिना चुनी गई प्रस्तुति पढ़ें |
| PUT | हाँ | प्रदान की गई स्थिति के साथ ज्ञात URI पर लक्ष्य संसाधन को प्रतिस्थापित या बनाएं |
| DELETE | हाँ | सुनिश्चित करें कि लक्ष्य संसाधन अनुपस्थित है |
| POST | गारंटी नहीं दी गई | एक सबमिशन को संसाधित करें जिसका प्रभाव लक्ष्य संसाधन द्वारा निर्दिष्ट है |
| PATCH | गारंटी नहीं दी गई | ऐसी आंशिक परिवर्तन लागू करें जो वर्तमान स्थिति पर निर्भर हो सकती है |
इडेम्पोटेंट अनुरोध निदान और परिचालन डिज़ाइन
एक डुप्लिकेट परिणाम सामान्यतः एक डेटा-मॉडल समस्या होती है न कि एक HTTP-लाइब्रेरी समस्या। क्लाइंट से गेटवे, एप्लिकेशन लॉग्स, डेटाबेस लेनदेन, और डाउनस्ट्रीम घटनाओं के माध्यम से तार्किक संचालन पहचानकर्ता को ट्रेस करें। यदि प्रत्येक डिलीवरी को एक नया कुंजी प्राप्त होता है, तो सर्वर उन्हें कनेक्ट नहीं कर सकता। यदि कुंजी स्थिर है लेकिन रिकॉर्ड व्यापार लेखन के बाद संग्रहीत किया जाता है, तो समवर्तीता अब भी दो श्रमिकों को पहले लुकअप को पास करने दे सकती है।
धारण आवश्यक एक जानबूझकर नीति है। एक कुंजी जिसे हमेशा के लिए रखा गया है, अनियंत्रित संग्रहण बनाती है; एक कुंजी जो बहुत जल्दी हटा दी गई है, धीमी या विलंबित डुप्लिकेट डिलीवरी की रक्षा नहीं कर सकती। सही समयावधि व्यापार प्रक्रिया, संदेश-डिलीवरी गारंटियों, और विवाद अवधि का पालन करती है। एक कुंजी फिर से उपयोग की गई है या नहीं, यह पहचानने के लिए पर्याप्त जानकारी संग्रहीत करें, और यदि वे व्यक्तिगत या संवेदनशील डेटा का संचालन करते हैं, तो संग्रहीत प्रतिक्रियाओं की सुरक्षा करें।
इडेम्पोटेंसी समवर्ती नियंत्रण को प्रतिस्थापित नहीं करती। दो अलग-अलग संचालन कुंजी अभी भी एक ही सूची सामग्री या खाता संतुलन पर दौड़ सकती हैं। डेटाबेस प्रतिबंध, परिस्थितिजन्य अद्यतनों, संस्करण क्षेत्रों, या साझा राज्य अविन्यास के लिए ताले का उपयोग करें। इडेम्पोटेंसी डुप्लिकेट इरादे को संभालती है; समवर्ती नियंत्रण प्रतिस्पर्धी इरादे को संभालती है।
इडेम्पोटेंट अनुरोध कार्यान्वयन चेकलिस्ट
नीचे दी गई चेकलिस्ट अवधारणा को सत्यापित इंजीनियरिंग कार्य में बदल देती है। केवल उन आइटमों को लागू करें जो सक्रिय प्रोटोकॉल और उत्पाद अनुबंध के साथ मेल खाते हैं, लेकिन साक्ष्य को एक साथ रखें ताकि एक और इंजीनियर निर्णय को पुनः निर्माण कर सके।
- ऐसी तार्किक कार्रवाई चुनें जो एक पहचान प्राप्त करती है और उस समय को दस्तावेजित करें जब एक क्लाइंट को नई पहचान बनानी होती है।
- खातों, अंत बिंदुओं, या संसाधनों द्वारा कुंजी का दायरा ताकि असंबंधित कॉलर्स आपस में टकरा न सकें।
- एक लोडेड पेलोड फिंगरप्रिंट के साथ कुंजी की तुलना करें और असंगत पुनः उपयोग को अस्वीकार करें।
- कारोबारी परिणाम और पहचान को लेनदेनात्मक रूप से सुसंगत अर्थों के साथ संग्रहीत करें।
- पहचान और परिणाम को लिए गए डुप्लिकेट डिलीवरी के लिए लौटाएं।
- वास्तविक डिलीवरी और व्यवसायीय समयसीमा के आधार पर एक धारणा विंडो सेट करें।
- एक ही कुंजी के साथ समवर्ती सबमिशनों का परीक्षण करें और पुष्टि करें कि केवल एक व्यावसायिक प्रभाव को प्रतिबद्ध किया गया है।
कार्यान्वयन के बाद, सामान्य व्यवहार, सीमाएं, गलतफहमी इनपुट, गायब स्थिति, समवर्ती गतिविधि, और जानबूझकर पहुँच मत देना एक नियंत्रित वातावरण में परीक्षण करें। प्रत्येक मामले के लिए अपेक्षित स्थिति, शरीर का आकार, अंत स्थिति, और स्थिति संक्रमण को रिकॉर्ड करें। उत्पादन निगरानी परीक्षण के दौरान उपयोग किए गए समान आयाम की रिपोर्ट करनी चाहिए ताकि एक घटना की तुलना एक ज्ञात मानक के साथ की जा सके।
प्रलेखन को इंटरफ़ेस के प्रत्येक पक्ष पर जिम्मेदारी नामांकित करनी चाहिए। ग्राहकों को आवश्यक क्षेत्रों, स्थिर पहचान, क्रमबद्ध नियम, सीमाएँ, टर्मिनल संकेत, और त्रुटि अर्थ की आवश्यकता होती है। ऑपरेटरों को आंतरिक नीति, भंडारण या रूटिंग निर्णय, अवलोकन क्षेत्रों, और सुरक्षित सार्वजनिक प्रतिक्रिया की आवश्यकता होती है। अस्पष्ट अनुबंध टीमें के लिए गलत परत में दृश्य लक्षण को ठीक करने का कारण बन सकती हैं।
इडेम्पोटेंट अनुरोधों के साथ सामान्य गलतियाँ
किसी एक क्षेत्र से सफलता, अनुपस्थिति, अनुमति, क्रम, या पूर्णता का अनुमान न करें बिना चारों ओर के अनुबंध के। स्थिति कोड, टोकन, पृष्ठ आकार, और परिवहन हेडर प्रत्येक एक संकीर्ण प्रश्न का उत्तर देते हैं। प्रतिक्रिया शरीर, विधि, पहचान, फ़िल्टर, प्रोटोकॉल संस्करण, और सर्वर दस्तावेज शेष अर्थ प्रदान करते हैं।
सरलता के नाम पर नैदानिक संदर्भ को न हटाएं। एक शॉर्ट लॉग लाइन जो अनुरोध पहचानकर्ता, लक्ष्य, संस्करण, दायरा, या सीमा को छोड़ देती है, एक छोटे दोष को अनुमान के घंटों में बदल सकती है। साथ ही, अवलोकनशीलता को क्रेडेंशियल्स, सत्र गुप्त, हस्ताक्षरित यूआरएल, और संवेदनशील पेलोड क्षेत्रों को छुपाना चाहिए।
एक अस्थायी परिचालन कार्यरूप को स्थायी अनुबंध में न बदलें। अंतर्निहित क्रम, अनुमति, रूटिंग, गति, फ्रेमिंग, या त्रुटि-मैपिंग समस्या को ठीक करें और एक पूर्वाग्रह जाँच जोड़ें। एक प्रणाली तब विश्वसनीय हो जाती है जब विफलता स्पष्ट और सीमित होती है, न कि जब एक मैनुअल रन पूरा होता है।
निष्कर्ष
एक इडेम्पोटेंट अनुरोध को एकत्र प्रक्रिया के द्वारा परिभाषित किया जाता है: एक अनुप्रयोग और कई समान अनुप्रयोगों का वही Intended प्रभाव है। HTTP विधियों उपयोगी डिफ़ॉल्ट प्रदान करती हैं, लेकिन उत्पादन एपीआई अभी भी सही अंत बिंदु व्यवहार, स्थिर संचालन पहचान, लेनदेनात्मक संग्रहण, लोड संघर्ष जांच, और अलग समवर्ती नियंत्रण की आवश्यकता होती है। इडेम्पोटेंसी का व्यापार अनुबंध का हिस्सा मानें, न कि ग्राहक-पक्ष की सुविधा।
क्या आप एक अधिक विश्वसनीय डेटा कार्यप्रविधि बनाने के लिए तैयार हैं?
इस गाइड में प्रोटोकॉल अवधारणाओं को एक दस्तावेजीकृत स्क्रैपलेस उत्पाद सतह से जोड़ें और हर एक अनुरोध को परिणाम के माध्यम से सबमिशन से मापने योग्य रखें।
आज ही साइन अप करें और पाएं $5 फ्री क्रेडिट — कोई क्रेडिट कार्ड आवश्यक नहीं है.
आपका $5 क्रेडिट प्राप्त करें →FAQ
क्या हर GET अनुरोध अद्वितीय है?
GET को सुरक्षित और अद्वितीय के रूप में परिभाषित किया गया है, लेकिन एक कार्यान्वयन इस अनुबंध का उल्लंघन कर सकता है। विश्लेषण और पहुंच लॉग आकस्मिक साइड इफेक्ट हैं; एक GET एंडपॉइंट जो एक व्यावसायिक संचय करता है, उसे गलत तरीके से डिज़ाइन किया गया है और उसे ऐसे तरीके का उपयोग करना चाहिए जिसकी सेमांटिक्स क्रिया से मेल खाती हो।
क्या DELETE अद्वितीय है अगर दूसरा प्रतिक्रिया 404 हो सकता है?
अद्वितीयता इच्छित प्रभाव से संबंधित है, न कि समान प्रतिक्रियाओं से। पहले удаления के बाद, संसाधन अनुपस्थित होता है। एक बाद का DELETE उसे अनुपस्थित ही छोड़ता है, भले ही सर्वर रिपोर्ट करे कि हटाने के लिए कोई वर्तमान प्रतिनिधित्व नहीं था।
क्या POST को अद्वितीय बनाया जा सकता है?
हाँ। एक सेवा एक अद्वितीय ऑपरेशन कुंजी को स्वीकार कर सकती है, इसे अनुरोध payload से बांध सकती है, प्रतिबद्ध परिणाम को संग्रहीत कर सकती है, और जब वही ऑपरेशन फिर से आता है तो उस परिणाम को वापस कर सकती है। यह व्यवहार एक अनुप्रयोग अनुबंध है न कि POST की एक डिफ़ॉल्ट संपत्ति।
क्या एक अद्वितीयता कुंजी वही होती है जो अनुरोध ID है?
ज़रूरी नहीं। एक अनुरोध ID अक्सर ट्रेसिंग के लिए एक परिवहन प्रयास की पहचान करती है, जबकि एक अद्वितीयता कुंजी एक से अधिक डिलीवरी में एक तार्किक व्यावसायिक क्रिया की पहचान करती है। सिस्टम दोनों ले जा सकते हैं क्योंकि उनके उद्देश्य और जीवनकाल भिन्न होते हैं।
क्या अद्वितीयता ठीक-एक्सेक्यूशन की गारंटी देती है?
नहीं। वितरित घटकों में ठीक-एक्सेक्यूशन एक व्यापक सिस्टम संपत्ति है। अद्वितीयता दोहराई गई निष्पादन को एक व्यावसायिक प्रभाव पर एकत्रित करने देती है, जो अक्सर एप्लिकेशनों की ज़रूरत की व्यावहारिक गारंटी होती है।