API दर सीमा क्या है?

Scrapeless Scraping API उन दस्तावेज़ डेटा अनुरोधों को स्वीकार करता है, जिनका उपयोग वर्तमान सेवा मार्गदर्शिका में दिखाए गए खाते और उत्पाद सीमाओं के खिलाफ योजना बनाई जानी चाहिए।

API दर सीमा एक सेवा नियम है जो नियंत्रित करता है कि एक कॉलर एक निर्दिष्ट अवधि या एक बार में कितनी अनुरोध कर सकता है। एक सीमा साझा क्षमता की सुरक्षा करती है, निष्पक्ष पहुंच का समर्थन करती है, और उपयोग को पूर्वानुमान योग्य बना सकती है। सही इकाई महत्वपूर्ण होती है: प्रति सेकंड अनुरोध, प्रति मिनट अनुरोध, समवर्ती नौकरियां, और मासिक क्रेडिट विभिन्न प्रश्नों के उत्तर देती हैं। किसी भी दूसरे से कोई निष्कर्ष नहीं निकाला जाना चाहिए।

एक क्लाईंट जो सीमा की अनदेखी करता है, उसे उन डेटा के बजाय एक प्रतिक्रिया मिल सकती है जिसकी उसे अपेक्षा थी। एक क्लाईंट जो अधिक सुधार करता है, वह उपलब्ध क्षमता को अनउपयोगित छोड़ सकता है। व्यावहारिक कार्य यह है कि प्रदाता की वास्तविक नीति की पहचान की जाए, मांग को मापा जाए, और अनुरोधों को इस तरह से शेड्यूल किया जाए कि एप्लिकेशन अपनी अधिकृत आवंटन के भीतर रहे।

एक API सीमा मापने वाला

एक समय-खिड़की नियम एक कॉलर को निर्धारित अवधि के दौरान श्रेयित अनुरोधों की गणना करता है। एक समानांतरता नियम उन संचालन की गणना करता है जो अभी भी प्रगति में हैं। एक उपयोग कोटा एक लंबी लेखांकन अवधि में बिल योग्य इकाइयों की गणना कर सकता है। ये उपाय सह-अस्तित्व में हो सकते हैं। एक ऐसा अनुप्रयोग जो अपने दैनिक कोटा के अंतर्गत है, वह अभी भी एक छोटे विस्फोट सीमा से अधिक हो सकता है, और एक धीमे से भेजने वाला ग्राहक अभी भी एक साथ बहुत से लंबे कार्य चला सकता है।

प्रदाता अनुरोधों को एक API कुंजी, उपयोगकर्ता, संगठन, IP पते, या ऑपरेशन को श्रेय दे सकते हैं। द HTTP 429 स्थिति व्याख्या नोट करता है कि कार्यान्वयन क्षेत्र में भिन्नता होती है। यह न मानें कि प्रति प्रक्रिया एक कुंजी स्वतंत्र क्षमता उत्पन्न करती है, या कि एक अलग एंडपॉइंट में समान सीमा है। खाते और एंडपॉइंट-विशिष्ट दस्तावेज़ पढ़ें।

इकाइयां भी स्पष्ट होनी चाहिए। एक अनुरोध एक ऐसा कार्य उत्पन्न कर सकता है जिसका काम प्रारंभिक उत्तर के बाद जारी रहता है। एक बैच अनुरोध एकल-items अनुरोध से एक अलग इकाई का उपभोग कर सकता है। यदि कोई प्रदाता केवल उपयोग क्रेडिट बैलेंस प्रकाशित करता है, तो यह अनिवार्य रूप से एक दर सीमा नहीं है। आपके कार्यक्रम को उन सभी नियमों को अलग-अलग मॉडल करना चाहिए ताकि वह उन नियमों का पालन कर सके जो वास्तव में लागू होते हैं।

क्यों सीमाएँ अस्तित्व में हैं और वे कहाँ लागू होती हैं

एक सेवा के पास सीमित गणना, नेटवर्क और डाउनस्ट्रीम क्षमता है। एक सीमा एक कॉलर के अचानक ट्रैफ़िक को अन्य callers को बिगाड़ने से रोक सकती है। यह तब भी आकस्मिक लोड को कम कर सकती है जब एक क्लाइंट लूप जानबूझकर अधिक अनुरोध भेजता है। नीति को एक गेटवे पर लागू किया जा सकता है इससे पहले कि अनुप्रयोग कोड अनुरोध को देखे, या किसी विशेष ऑपरेशन के अंदर एक अधिक विशिष्ट लागत मॉडल के साथ।

एक अपस्ट्रीम वेबसाइट और एपीआई प्रदाता अलग-अलग सिस्टम हैं। एक स्क्रैपिंग एपीआई के पास अपने स्वयं के खाता नियंत्रण हो सकते हैं जबकि लक्षित वेबसाइटों के पास स्वतंत्र पहुँच और ट्रैफ़िक नियम होते हैं। प्रदाता की क्षमता आवंटन लक्षित के लागू शर्तों या पहुँच प्रतिबंधों की अनदेखी करने की अनुमति नहीं देता है। अधिकृत डेटा और जिस सेवा को आप कॉल कर रहे हैं, उसकी वास्तविक सीमाओं के चारों ओर संग्रह की योजना बनाएं।

The HTTP स्थिति विस्तार 429 को परिभाषित करना एक सर्वर को यह सूचित करने की अनुमति देता है कि एक कॉलर ने एक अवधि में बहुत अधिक अनुरोध भेजे हैं। यह एक सार्वभौमिक गणना एल्गोरिदम को परिभाषित नहीं करता है। यह चयन सेवा का है। क्लाइंट कोड को प्रकाशित नीति और अवलोकित प्रतिक्रिया फ़ील्ड पर निर्भर करना चाहिए न कि किसी विशिष्ट बकेट कार्यान्वयन का अनुमान लगाने पर।

HTTP 429 को कैसे पढ़ें

HTTP 429 बहुत अधिक अनुरोध संकेत करता है कि कॉल करने वाले ने एक दर नियंत्रण को पार कर लिया है। यह एक विकृत अनुरोध या एक गायब क्रेडेंशियल से भिन्न है। एक प्रतिक्रिया यह बता सकती है कि कौन सा नियम पार किया गया और यह संकेत कर सकती है कि कॉल करने वाले को अधिक अनुरोध जारी करने से पहले कितनी देर प्रतीक्षा करनी चाहिए। बॉडी और हेडर प्रदाता-विशिष्ट होते हैं, इसलिए संबंधित क्षेत्रों को लॉग करें बिना किसी रहस्य को उजागर किए।

स्थिति अकेले यह नहीं बताती है कि सीमा एक एन्डपॉइंट, पूरे खाते, या साझा IP से जुड़ी है या नहीं। अनुरोध समय मुहर, कुंजी, संचालन, और समवर्ती कार्यभार की तुलना प्रलेखित नीति के खिलाफ करें। यदि कई श्रमिक एक ही आवंटन साझा करते हैं, तो एक श्रमिक की स्थानीय गणना कुल को स्पष्ट नहीं कर सकती। केंद्रीय रूप से समन्वय करें या उपलब्ध होने पर प्रदाता उपयोग डेटा का उपयोग करें।

हर गैर-200 परिणाम का इलाज दर सीमित करने के रूप में न करें। एक्सेस अस्वीकृति, प्रमाणीकरण विफलता, और उपलब्ध नहीं होने वाली अपस्ट्रीम स्रोत विभिन्न प्रतिक्रियाओं की आवश्यकता कर सकते हैं। शेड्यूल बदलने से पहले वास्तविक स्थिति और दस्तावेज़ीकृत त्रुटि को वर्गीकृत करें। HTTP सेमांटिक्स मानक वह व्यापक स्थिति संदर्भ प्रदान करता है जो उन श्रेणियों को अलग रखने में मदद करता है।

ज्ञात आवंटन के भीतर काम का कार्यक्रम बनाना

एक ग्राहक लंबित कार्य को एक कतार में रख सकता है और इसे प्रदाता द्वारा प्रकाशित नियम के अनुसार जारी कर सकता है। एक निश्चित अनुरोध विंडो के लिए, साझा खाते को संबोधित अनुरोधों को ट्रैक करें और इसकी अनुमति से अधिक भेजने से बचें। एक समवर्ती सीमा के लिए, एक नया कार्य तब जारी करें जब एक मौजूदा कार्य पूरा हो जाए। ये नियंत्रण प्रदाता की वास्तविक इकाइयों का प्रतिनिधित्व करना चाहिए न कि हर कॉल के बीच एक मनमाना विश्राम।

विभिन्न ऑपरेशन का समय या क्रेडिट्स की लागत अलग-अलग हो सकती है। यदि देरी मायने रखती है, तो इंटरएक्टिव अनुरोधों के लिए शेड्यूल को बैकग्राउंड संग्रह से अलग करें। केवल तभी आपातकालीन पथ के लिए क्षमता आरक्षित करें जब प्रदाता नीति और व्यवसाय की जरूरतें इसे सही ठहराए। एक कतार काम को डुप्लिकेट करने के लिए एक स्थान भी देती है: एक ही अपरिवर्तित रिकॉर्ड के लिए कई बार पूछना आवंटन का व्यय कर सकता है बिना परिणाम में सुधार किए।

जब एक प्रदाता उपयोग हेडर या डैशबोर्ड काउंटर प्रदान करता है, तो उन्हें क्लाइंट-साइड के लेखा-जोखा के साथ तुलना करें। वे अन्य प्रक्रियाओं को प्रकट कर सकते हैं जो उसी कुंजी का उपयोग कर रही हैं या एक नियम जो अपेक्षा से अलग गिनती करता है। किसी अनुमानित सीमा को प्रकाशित मार्गदर्शन में हार्ड-कोड न करें। वर्तमान प्रदाता दस्तावेज़ से संबंधित एक कॉन्फ़िगरेशन मान का उपयोग करें और जब सेवा बदलती है तो इसकी समीक्षा करें।

रेट लिमिट, क्रेडिट और डेटा ताज़गी

एक दर सीमा गति को नियंत्रित करती है, जबकि एक क्रेडिट बैलेंस या योजना भत्ता खपत को नियंत्रित करता है। एक वर्कफ़्लो एक को फिट कर सकता है और दूसरे का उल्लंघन कर सकता है। एक रन के लिए स्रोत रिकॉर्ड, अभिनेता कॉल और परिणाम निरीक्षणों की संख्या का अनुमान लगाएं। फिर जांचें कि उत्पाद कैसे चार्ज करता है और क्या असिंक्रोनस ऑपरेशन्स सबमिशन, पूर्णता, या किसी अन्य प्रलेखित चरण पर गिनती करते हैं।

ताजगी लक्ष्य क्षमता से टकरा सकते हैं। यदि एक सूची को दैनिक अपडेट की आवश्यकता है लेकिन आवंटन हर दिन हर आइटम को कवर नहीं कर सकता है, तो उन रिकॉर्ड्स को प्राथमिकता दें जो कितनी बार बदलते हैं और वे कितने महत्वपूर्ण हैं। उपभोक्ताओं को इसकी आयु देखने के लिए प्रत्येक रिकॉर्ड के साथ अवलोकन का समय संग्रहीत करें। वर्तमान के रूप में एक पुरानी मात्रा प्रस्तुत न करें केवल इस कारण कि एपीआई प्रतिक्रिया वाक्यात्मक रूप से सफल थी।

द स्क्रेपलेस स्क्रैपिंग एपीआई प्रलेखन समर्थित अभिनेता वर्कफ़्लो की पहचान करता है; उत्पाद अवलोकन संरचित डेटा पहुँच का वर्णन करता है। लागू क्षमता के लिए वर्तमान खाता उपयोग और उत्पाद मार्गदर्शन परामर्श करें। संबंधित अभिनेता मार्गदर्शिका मांग की योजना बनाते समय कार्य-आधारित प्रवाह से तात्कालिक परिणामों को भेद करने में मदद करती है।

एक अप्रत्याशित सीमा का निदान

पहले ठीक उत्तर और उस संचालन की पहचान करें जिसने इसे उत्पन्न किया। जांचें कि क्या अनुरोध ने इरादित कुंजी का उपयोग किया और क्या पृष्ठभूमि के कार्यकर्ता उस कुंजी को साझा करते हैं। वर्तमान ट्रैफ़िक की तुलना विशिष्ट उत्पाद और एंडपॉइंट के लिए नीति से करें। एक स्थानीय प्रक्रिया जो प्रति सेकंड एक अनुरोध भेजती है, फिर भी एक बेड़े का हिस्सा हो सकती है जो एक खाते की सीमा से अधिक हो।

अगला कार्य जीवनचक्र और डुप्लीकेशन की जांच करें। जब एक असिंक्रोनस परिणाम को अधिक बार निगरानी की जाती है जितना कि प्रलेखन की आवश्यकता है, तो यह अनुरोधों का उपभोग कर सकता है बिना अंतर्निहित कार्य को तेज किए। ओवरलैपिंग शेड्यूल द्वारा ट्रिगर किए गए डुप्लिकेट कार्य एक ही कर सकते हैं। एक कैप अनुरोध उठाने से पहले कार्य प्रवाह मॉडल को सही करें; अन्यथा अतिरिक्त क्षमता केवल बर्बादी को बढ़ा सकती है।

अंत में, एक प्रलेखित सीमा और एक देखा गया अस्थायी स्थिति के बीच का भेद बनाए रखें। एकल 429 यह साबित करता है कि इस अनुरोध ने एक सक्रिय नियम को पार किया; यह हर थ्रेशोल्ड या एक स्थायी नीति मूल्य की गारंटी नहीं करता है। प्रदाता से एक विशिष्ट प्रश्न पूछने के लिए आवश्यक सबूत को रिकॉर्ड करें, और ग्राहक व्यवहार को उस आवंटन के भीतर रखें जो वास्तव में पुष्टि की गई है।

निष्कर्ष

एपीआई दर सीमाएँ अनुरोध की गति या एक प्रदाता-परिभाषित आवंटन के भीतर समवर्ती कार्यों को नियंत्रित करती हैं। समझें कि काउंट किया जा रहा है, श्रमिकों के बीच लेखा साझा करें, और प्रकाशित नीति के संदर्भ में HTTP 429 की व्याख्या करें। एक उचित अनुसूची सेवा क्षमता और डेटा कार्यप्रवाह की गुणवत्ता दोनों की रक्षा करती है।