एपीआई दर सीमित करना क्या है?

स्क्रेपलेस स्क्रैपिंग एपीआई दस्तावेज़ अनुरोध परिणाम और प्राधिकृत वेब-डेटा कार्यों के लिए कोटा संबंधित स्थिति प्रबंधन प्रदान करता है।

परिभाषा और संक्षिप्त उत्तर

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

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

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

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

एक दर सीमित करने वाला निर्णय कैसे करता है

1. कॉलर और दायरा पहचानें। गेटवे या सेवा खाते, क्रेडेंशियल, उपयोगकर्ता, मार्ग, और अन्य आयामों को हल करती है जो लागू नीति का चयन करते हैं। गुमनाम ट्रैफ़िक को नेटवर्क पते द्वारा समूहित किया जा सकता है, जबकि प्राधिकृत ट्रैफ़िक टेनेट-जानकारी सीमाओं का उपयोग कर सकता है।
2. ऑपरेशन की लागत की गणना करें। एक साधारण सीमित करने वाला एक अनुरोध प्रति एक इकाई गिनता है। एक वजनदार सीमित करने वाला जटिल खोजों, बड़े पृष्ठों, ब्राउज़र सत्रों, या कार्यों के लिए अधिक इकाइयों की चार्ज कर सकता है जो महत्वपूर्ण कंप्यूट और डाउनस्ट्रीम क्षमता का उपभोग करते हैं।
3. उपलब्ध क्षमता की जांच करें। सीमित करने वाला वर्तमान विंडो या बकेट के लिए अनुमति पढ़ता या गणना करता है। वितरित प्रवर्तन को लगातार स्थिति, सावधानीपूर्वक घड़ी प्रबंधन, और क्षेत्रीय या गेटवे-स्थानीय काउंटरों के लिए स्पष्ट नीति की आवश्यकता होती है।
4. डेटा या सीमा प्रतिक्रिया लौटाएँ। अनुमति प्राप्त कार्य जारी रहता है और क्षमता का उपभोग करता है। अस्वीकृत कार्य को 429 या दस्तावेजित सेवा प्रतिक्रिया प्राप्त होती है। ग्राहकों को अपनी प्रस्तुतियों की गति को धीमा करना चाहिए, stated wait interval का सम्मान करना चाहिए, और समवर्ती विस्फोटों से बचना चाहिए।

वास्तविक प्रणालियों में एपीआई दर सीमित करना

सामान्य दर-सीमित करने वाले एल्गोरिदम

एक बगल-दर-बगल दृश्य आसन्न अवधारणाओं को एक समान के रूप में व्यवहार करने से रोकता है। तुलना का उपयोग करें यह पहचानने के लिए कि क्लाइंट या सर्वर व्यवहार बदलने से पहले कौन सा अनुबंध सक्रिय है।

API दर सीमा निदान और संचालन डिजाइन

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

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

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

API दर सीमा कार्यान्वयन चेकलिस्ट

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

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

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

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

API दर सीमाएँ के साथ सामान्य गलतियाँ

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

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

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

निष्कर्ष

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