कोटा नीति

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं.
जानकारी

यह क्या है

कोटा नीति का इस्तेमाल करके, अनुरोध वाले ऐसे मैसेज की संख्या कॉन्फ़िगर करें जिन्हें एपीआई प्रॉक्सी किसी तय समयावधि में अनुमति देता है. जैसे, एक मिनट, घंटे, दिन, हफ़्ते या महीने. एपीआई प्रॉक्सी को ऐक्सेस करने वाले सभी ऐप्लिकेशन के लिए, कोटा को एक जैसा रखा जा सकता है. इसके अलावा, इनके आधार पर भी कोटा सेट किया जा सकता है:

  • वह प्रॉडक्ट जिसमें एपीआई प्रॉक्सी शामिल है
  • एपीआई के लिए अनुरोध करने वाला ऐप्लिकेशन
  • ऐप्लिकेशन डेवलपर
  • कई और शर्तें

ट्रैफ़िक में होने वाली कुल बढ़ोतरी से बचने के लिए, कोटा का इस्तेमाल न करें. इसके लिए, स्पाइक अरेस्ट नीति का इस्तेमाल करें. स्पाइक अरेस्ट की नीति देखें.

वीडियो

इन वीडियो में, कोटा नीति के साथ कोटा मैनेजमेंट की जानकारी दी गई है:

इंट्रो (न्यू एज)

इंट्रो (क्लासिक एज)

डाइनैमिक कोटा

डिस्ट्रिब्यूटेड और सिंक्रोनस

मैसेज का वज़न

Calendar

रोलिंग विंडो

फ़्लेक्सी

शर्त वाला कोटा

फ़्लो वैरिएबल

गड़बड़ी ठीक करना

सैंपल

इन नीति कोड के उदाहरणों में, इन तरीकों से कोटा अवधि को शुरू और खत्म करने के तरीके बताए गए हैं:

ज़्यादा डायनैमिक कोटा

<Quota name="CheckQuota"> 
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

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

ध्यान दें: अगर किसी एलिमेंट के लिए वैल्यू और रेफ़रंस, दोनों तय किए जाते हैं, तो रेफ़रंस को प्राथमिकता दी जाती है. अगर रनटाइम के दौरान रेफ़रंस की समस्या हल नहीं होती, तो इस वैल्यू का इस्तेमाल किया जाता है.

उदाहरण के लिए, कोई एपीआई प्रॉडक्ट बनाते समय, आपके पास स्वीकार किए गए कोटे की सीमा, समय की इकाई, और इंटरवल सेट करने का विकल्प होता है. हालांकि, एपीआई प्रॉडक्ट पर इन वैल्यू को सेट करने से, एपीआई प्रॉक्सी में इनका इस्तेमाल लागू नहीं होता. आपको एपीआई प्रॉक्सी में कोटा नीति भी जोड़नी होगी, जो इन वैल्यू को पढ़ती है. ज़्यादा जानकारी के लिए, एपीआई प्रॉडक्ट बनाना देखें.

ऊपर दिए गए उदाहरण में, कोटा नीति का इस्तेमाल करने वाली एपीआई प्रॉक्सी, किसी अनुरोध में पास की गई एपीआई पासकोड की पुष्टि करने के लिए, verify-api-key नाम की पुष्टि APIKey नीति का इस्तेमाल करती है. इसके बाद, कोटा नीति, एपीआई प्रॉडक्ट पर सेट किए गए कोटा की वैल्यू को पढ़ने के लिए,VerifyAPIKey नीति के फ़्लो वैरिएबल को ऐक्सेस करती है. पुष्टि करने के एपीआई के फ़्लो वैरिएबल के बारे में ज़्यादा जानने के लिए, एपीआई पासकोड से जुड़ी नीति की पुष्टि करें देखें.

दूसरा विकल्प यह है कि अलग-अलग डेवलपर या ऐप्लिकेशन पर कस्टम एट्रिब्यूट सेट करें. इसके बाद, उन वैल्यू को कोटा नीति में पढ़ें. उदाहरण के लिए, आपको हर डेवलपर के लिए अलग-अलग कोटा वैल्यू सेट करनी है. इस मामले में, उन डेवलपर पर कस्टम एट्रिब्यूट सेट किए जा सकते हैं जिनमें ऐप्लिकेशन की समयसीमा, समय, और इंटरवल की जानकारी शामिल हो. इसके बाद, कोटा नीति में इन वैल्यू का रेफ़रंस दिया जा सकता है, जैसा कि नीचे दिखाया गया है:

<Quota name="DeveloperQuota"> 
  <Identifier ref="verifyapikey.verify-api-key.client_id"/> 
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> 
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> 
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> 
</Quota>

इस उदाहरण में, Developer पर सेट किए गए कस्टम एट्रिब्यूट का रेफ़रंस देने के लिए, VerificationAPIKey फ़्लो वैरिएबल का इस्तेमाल किया जाता है.

कोटा नीति के पैरामीटर सेट करने के लिए, किसी भी वैरिएबल का इस्तेमाल किया जा सकता है. ये वैरिएबल यहां से लिए जा सकते हैं:

  • फ़्लो वैरिएबल
  • एपीआई प्रॉडक्ट, ऐप्लिकेशन या डेवलपर पर प्रॉपर्टी
  • की-वैल्यू मैप (केवीएम)
  • हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर वगैरह

हर एपीआई प्रॉक्सी के लिए, एक कोटा नीति जोड़ी जा सकती है, जो अन्य सभी प्रॉक्सी में उसी वैरिएबल के बारे में बताती हो जिस पर दूसरी सभी प्रॉक्सी नीतियों का वैरिएबल होता है या कोटा नीति में उस नीति और प्रॉक्सी के लिए यूनीक वैरिएबल का रेफ़रंस दिया जा सकता है.

प्रारंभ समय

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

type वाले कोटा के लिए, आपको calendar पर सेट की गई <StartTime> की वैल्यू साफ़ तौर पर देनी होगी. समय की वैल्यू जीएमटी समय है, न कि स्थानीय समय. अगर आप calendar टाइप की नीति के लिए <StartTime> वैल्यू नहीं देते हैं, तो Edge से गड़बड़ी हो जाती है.

हर ऐप्लिकेशन के लिए कोटा काउंटर को <StartTime>, <Interval>, और <TimeUnit> वैल्यू के आधार पर रीफ़्रेश किया जाता है. इस उदाहरण के लिए, कोटे की गिनती 18 फ़रवरी, 2017 को सुबह 10:30 बजे जीएमटी से शुरू होती है और हर पांच घंटे में रीफ़्रेश होती है. इसलिए, अगला रीफ़्रेश 18 फ़रवरी, 2017 को दोपहर 3:30 बजे जीएमटी पर होगा.

ऐक्सेस काउंटर

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

एपीआई प्रॉक्सी के पास कोटा नीति के ज़रिए सेट किए गए फ़्लो वैरिएबल का ऐक्सेस होता है. कंडिशनल प्रोसेसिंग करने, कोटा की सीमा के करीब पहुंचने पर, ऐप्लिकेशन में मौजूदा कोटा काउंटर को वापस लाने, या अन्य वजहों से, इन फ़्लो वैरिएबल को एपीआई प्रॉक्सी में ऐक्सेस किया जा सकता है.

इस नीति के फ़्लो वैरिएबल का ऐक्सेस, नीतियों के मुताबिक name एट्रिब्यूट पर आधारित होता है. इसलिए, ऊपर दी गई नीति QuotaPolicy के लिए, इसके फ़्लो वैरिएबल को इस फ़ॉर्म में ऐक्सेस किया जा सकता है:

  • ratelimit.QuotaPolicy.allowed.count: अनुमति वाली संख्या.
  • ratelimit.QuotaPolicy.used.count: मौजूदा काउंटर वैल्यू.
  • ratelimit.QuotaPolicy.expiry.time: काउंटर रीसेट होने पर यूटीसी समय.

कई अन्य फ़्लो वैरिएबल ऐक्सेस किए जा सकते हैं, जैसा कि नीचे बताया गया है.

उदाहरण के लिए, कोटा फ़्लो वैरिएबल की वैल्यू को रिस्पॉन्स हेडर के तौर पर दिखाने के लिए, इस Assignments मैसेज की नीति का इस्तेमाल किया जा सकता है:

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

पहला अनुरोध

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

हर घंटे 10,000 कॉल का कोटा लागू करने के लिए, इस सैंपल कोड का इस्तेमाल करें. यह नीति, हर घंटे के ऊपर कोटा काउंटर को रीसेट करती है. अगर काउंटर घंटा खत्म होने से पहले ही 10,000 कॉल कोटा तक पहुंच जाता है, तो 10,000 से ज़्यादा कॉल अस्वीकार कर दिए जाते हैं.

उदाहरण के लिए, अगर काउंटर 2017-07-08 07:00:00 से शुरू होता है, तो यह 2017-07-08 08:00:00 बजे (शुरुआत से 1 घंटे) पर 0 पर रीसेट हो जाता है. अगर पहला मैसेज 2017-07-08 07:35:28 पर मिला है और मैसेज की संख्या 2017-07-08 08:00:00 से पहले 10,000 तक पहुंच गई है, तो इस संख्या से ज़्यादा कॉल को अस्वीकार कर दिया जाएगा. ऐसा तब तक होगा, जब तक घंटे के सबसे ऊपर यह संख्या रीसेट नहीं हो जाती.

काउंटर रीसेट का समय <Interval> और <TimeUnit> के कॉम्बिनेशन के हिसाब से तय होता है. उदाहरण के लिए, अगर आप <TimeUnit> घंटे के लिए <Interval> को 12 पर सेट करते हैं, तो काउंटर हर बारह घंटे में रीसेट होगा. <TimeUnit> को मिनट, घंटे, दिन, हफ़्ते या महीने में सेट किया जा सकता है.

अपने एपीआई प्रॉक्सी में एक से ज़्यादा जगहों पर, इस नीति का रेफ़रंस दिया जा सकता है. उदाहरण के लिए, इसे प्रॉक्सी PreFlow पर रखा जा सकता है, ताकि हर अनुरोध पर इसे लागू किया जा सके. इसके अलावा, इसे एपीआई प्रॉक्सी में एक से ज़्यादा फ़्लो पर भी डाला जा सकता है. अगर प्रॉक्सी में एक से ज़्यादा जगहों पर इस नीति का इस्तेमाल किया जाता है, तो एक ही काउंटर को सभी जगहों पर अपडेट किया जाता है.

इसके अलावा, अपने एपीआई प्रॉक्सी में एक से ज़्यादा कोटा नीतियां भी जोड़ी जा सकती हैं. कोटा की हर नीति के तहत, अपना अलग काउंटर बनाया जाता है. ऐसा, नीति के name एट्रिब्यूट के आधार पर किया जाता है.

आइडेंटिफ़ायर सेट करें

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/> 
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

डिफ़ॉल्ट रूप से, कोटा नीति के तहत एपीआई प्रॉक्सी के लिए एक ही काउंटर होता है. भले ही, अनुरोध किसी भी वजह से किया गया हो. इसके अलावा, <Identifier> एट्रिब्यूट की वैल्यू के आधार पर अलग-अलग काउंटर बनाए रखने के लिए, कोटा नीति के साथ <Identifier> एट्रिब्यूट का इस्तेमाल किया जा सकता है.

उदाहरण के लिए, हर क्लाइंट आईडी के लिए अलग-अलग काउंटर बनाने के लिए, <Identifier> टैग का इस्तेमाल करें. जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है, आपके प्रॉक्सी के अनुरोध पर क्लाइंट ऐप्लिकेशन, clientID वाला हेडर पास करता है.

<Identifier> एट्रिब्यूट के लिए, किसी भी फ़्लो वैरिएबल को तय किया जा सकता है. उदाहरण के लिए, यह बताया जा सकता है कि id नाम के क्वेरी पैरामीटर में यूनीक आइडेंटिफ़ायर है:

<Identifier ref="request.queryparam.id"/>

अगर एपीआई पासकोड की पुष्टि करने के लिए, पुष्टि करने के लिए APIKey नीति या OAuth टोकन के साथ OAuthV2 नीतियों का इस्तेमाल किया जाता है, तो एक जैसी कोटा नीति के लिए अलग-अलग काउंटर तय करने के लिए, एपीआई पासकोड या टोकन में दी गई जानकारी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, यहां दिया गया <Identifier> टैग, verify-api-key नाम की VerificationAPIKey नीति के client_id फ़्लो वैरिएबल का इस्तेमाल करता है:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

client_id की हर यूनीक वैल्यू, अब कोटा नीति में अपना काउंटर तय करती है.

कक्षा

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

क्लास के हिसाब से कोटा की गिनती का इस्तेमाल करके, डाइनैमिक तौर पर कोटे की सीमाएं सेट की जा सकती हैं. इस उदाहरण में, कोटे की सीमा, हर अनुरोध के साथ पास किए गए developer_segment हेडर की वैल्यू से तय की जाती है. उस वैरिएबल की वैल्यू platinum या silver हो सकती है. अगर हेडर में अमान्य वैल्यू है, तो नीति कोटा के उल्लंघन से जुड़ी गड़बड़ी की जानकारी दिखाती है.


कोटा नीति के बारे में जानकारी

कोटा, अनुरोध वाले मैसेज का एक हिस्सा होता है. एपीआई प्रॉक्सी एक तय समयावधि जैसे मिनट, घंटे, दिन, हफ़्ते या महीने में इन मैसेज को मैनेज कर सकता है. नीति में ऐसे काउंटर हैं जो एपीआई प्रॉक्सी से मिले अनुरोधों की संख्या के हिसाब से जांच करते हैं. इस सुविधा की मदद से, एपीआई सेवा देने वाली कंपनियां एक तय अवधि में ऐप्लिकेशन से किए जाने वाले एपीआई कॉल की संख्या पर सीमा लागू कर सकती हैं. उदाहरण के लिए, कोटा नीतियों का इस्तेमाल करके, ऐप्लिकेशन को एक मिनट में एक अनुरोध या हर महीने 10,000 अनुरोधों तक सीमित किया जा सकता है.

उदाहरण के लिए, अगर किसी कोटे के तहत हर महीने 10,000 मैसेज भेजे जाते हैं, तो अनुरोध भेजने की दर की सीमा 10,000वें मैसेज के बाद शुरू होती है. इस बात से कोई फ़र्क़ नहीं पड़ता कि उस अवधि के पहले दिन 10,000 मैसेज गिने गए थे या आखिरी दिन. जब तक तय किए गए समय अंतराल के आखिर में कोटा काउंटर अपने-आप रीसेट नहीं होता या तब तक के लिए, कोटा रीसेट करने की नीति का इस्तेमाल करके साफ़ तौर पर रीसेट नहीं किया जाता, तब तक किसी भी अतिरिक्त अनुरोध के लिए अनुमति नहीं दी जाती.

SpikeArrest नाम के कोटा में अंतर होने से, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी (या एक क्लिक की संख्या में अचानक होने वाली बढ़ोतरी) से बचा जा सकता है. ऐसा, इस्तेमाल, बग्गी क्लाइंट या नुकसान पहुंचाने वाले हमलों में अचानक बढ़ जाने की वजह से हो सकता है. SpikeArr के बारे में ज़्यादा जानकारी के लिए, Spike Arest की नीति देखें.

कोटा, अलग-अलग एपीआई प्रॉक्सी पर लागू होते हैं और उन्हें एपीआई प्रॉक्सी के बीच बांटा नहीं जाता. उदाहरण के लिए, अगर आपके पास किसी एपीआई प्रॉडक्ट में तीन एपीआई प्रॉक्सी हैं, तो तीनों में एक कोटा शेयर नहीं किया जाता. भले ही, तीनों एक ही कोटा नीति के कॉन्फ़िगरेशन का इस्तेमाल करते हों.

कोटा से जुड़ी नीति के टाइप

कोटा नीति कई अलग-अलग तरह की नीतियों के साथ काम करती है: डिफ़ॉल्ट, calendar, flexi, और rollingwindow. हर टाइप से तय होता है कि कोटा काउंटर कब शुरू होगा और यह कब रीसेट होगा, जैसा कि इस टेबल में दिखाया गया है:

समय इकाई डिफ़ॉल्ट (या शून्य) रीसेट कैलेंडर रीसेट करो फ़्लेक्सी रीसेट करें
मिनट अगले मिनट की शुरुआत <StartTime> के एक मिनट बाद पहले अनुरोध के एक मिनट बाद
hour अगले घंटे का शीर्ष <StartTime> के एक घंटे बाद पहले अनुरोध के एक घंटे बाद
दिन आज के दिन की आधी रात का जीएमटी <StartTime> के 24 घंटे बाद पहले अनुरोध के 24 घंटे बाद
हफ़्ता हफ़्ते के आखिर में, रविवार की आधी रात जीएमटी <StartTime> के एक हफ़्ते बाद पहले अनुरोध के एक हफ़्ते बाद
महीना महीने के आखिरी दिन की आधी रात जीएमटी <StartTime> के बाद एक महीने (28 दिन) पहले अनुरोध के एक महीने (28 दिन) बाद

type="calendar" के लिए, आपको <StartTime> की वैल्यू बतानी होगी.

टेबल में rollingwindow टाइप की वैल्यू शामिल नहीं की गई है. रोलिंग विंडो कोटा को एक "विंडो" के साइज़ के हिसाब से सेट किया जाता है, जैसे कि एक घंटे या एक दिन की विंडो. जब कोई नया अनुरोध मिलता है, तो नीति यह तय करती है कि क्या पिछली "विंडो" में कोटा पार हुआ है या नहीं.

उदाहरण के लिए, आपने दो घंटे की विंडो तय की है जिसमें 1,000 अनुरोध शामिल किए जा सकते हैं. नया अनुरोध दोपहर 4:45 बजे का होता है. इस नीति के तहत, पिछले दो घंटे में मिले अनुरोधों की संख्या का हिसाब लगाया जाता है. इसका मतलब है, दोपहर 2:45 बजे से अब तक मिले अनुरोधों की संख्या. अगर दो घंटे की अवधि में कोटा की सीमा पार नहीं होती है, तो अनुरोध को अनुमति दी जाती है.

एक मिनट बाद, शाम 4:46 पर, दूसरा अनुरोध आता है. अब नीति में कोटे की संख्या, दोपहर 2:46 बजे से कैलकुलेट की जाती है, ताकि यह पता लगाया जा सके कि स्टोरेज की तय सीमा पार हुई है या नहीं.

rollingwindow टाइप के लिए, काउंटर कभी रीसेट नहीं होता. हालांकि, हर अनुरोध के लिए इसका फिर से हिसाब लगाया जाता है.

कोटा काउंटर को समझना

डिफ़ॉल्ट रूप से, कोटा नीति में एक ही काउंटर होता है. इस बात से कोई फ़र्क़ नहीं पड़ता कि आपने एपीआई प्रॉक्सी में कितनी बार उसका रेफ़रंस दिया है. कोटा काउंटर का नाम, इस नीति के name एट्रिब्यूट के आधार पर दिया जाता है.

उदाहरण के लिए, पांच अनुरोधों की सीमा के साथ MyQuotaPolicy नाम की कोटा नीति बनाई जाती है और उसे एपीआई प्रॉक्सी में एक से ज़्यादा फ़्लो (फ़्लो A, B, और C) पर रखा जाता है. भले ही, इसका इस्तेमाल कई फ़्लो में किया जाता है, लेकिन इसमें एक ही काउंटर होता है जिसे नीति के सभी मामलों में अपडेट किया जाता है:

  • फ़्लो A लागू किया जाता है -> My इन्वेंट्री का इस्तेमाल किया जाता है और इसका काउंटर = 1 होता है
  • फ़्लो B लागू किया जाता है -> Myकोट नीति लागू की जाती है और इसका काउंटर = 2
  • फ़्लो A लागू किया जाता है -> MyotPolicy लागू किया जाता है और इसका काउंटर = 3 है
  • फ़्लो C लागू किया जाता है -> Myकोट नीति लागू की जाती है और इसका काउंटर = 4
  • फ़्लो A लागू किया जाता है -> Myकोट नीति लागू की जाती है और इसका काउंटर = 5 है

तीनों में से किसी भी फ़्लो का अगला अनुरोध अस्वीकार कर दिया जाता है, क्योंकि कोटा काउंटर तय सीमा तक पहुंच चुका है.

एपीआई प्रॉक्सी फ़्लो में एक से ज़्यादा जगहों पर एक ही कोटा नीति का इस्तेमाल करना. इससे अनजाने में कोटा आपकी उम्मीद से ज़्यादा जल्दी खत्म हो सकता है. इस नीति के बारे में The Book of Apigee Edge Antipatterns में बताए गए पैटर्न का पालन नहीं करना है.

इसके अलावा, अपने एपीआई प्रॉक्सी में एक से ज़्यादा कोटा नीतियां जोड़ी जा सकती हैं और हर फ़्लो में, एक अलग नीति का इस्तेमाल किया जा सकता है. कोटा की हर नीति का अपना अलग कानूनी विरोध होता है. ऐसा, नीति के name एट्रिब्यूट के आधार पर किया जाता है.

इसके अलावा, कोटा नीति में <Class> या <Identifier> एलिमेंट का इस्तेमाल करके, किसी एक नीति में कई और यूनीक काउंटर तय किए जा सकते हैं. इन एलिमेंट का इस्तेमाल करके, एक ही नीति कई चीज़ों के आधार पर अलग-अलग काउंटर बनाए रख सकती है. इनमें, अनुरोध करने वाले ऐप्लिकेशन, अनुरोध करने वाले ऐप्लिकेशन डेवलपर, क्लाइंट आईडी या अन्य क्लाइंट आइडेंटिफ़ायर वगैरह शामिल हैं. <Class> या <Identifier> एलिमेंट के इस्तेमाल के बारे में ज़्यादा जानने के लिए, ऊपर दिए गए उदाहरण देखें.

टाइम नोटेशन

सभी कोटा समय, कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी) टाइम ज़ोन के हिसाब से सेट किए जाते हैं.

कोटा समय का नोटेशन, अंतरराष्ट्रीय मानक ISO 8601 में बताए गए अंतरराष्ट्रीय मानक तारीख के नोटेशन के मुताबिक होता है.

तारीख को साल, महीने, और दिन के तौर पर, इस फ़ॉर्मैट में बताया गया है: YYYY-MM-DD. उदाहरण के लिए, 2015-02-04 से 4 फ़रवरी, 2015 का पता चलता है.

दिन के समय को इस फ़ॉर्मैट में घंटे, मिनट, और सेकंड के तौर पर बताया गया है: hours:minutes:seconds. उदाहरण के लिए, 23:59:59 आधी रात से एक सेकंड पहले के समय को दिखाता है.

ध्यान दें कि दो संकेतन, 00:00:00 और 24:00:00, ऐसी दो आधी रात के बीच अंतर करने के लिए उपलब्ध हैं जो एक ही तारीख से जुड़े हो सकते हैं. इसलिए, 2015-02-04 24:00:00 और 2015-02-05 00:00:00 एक ही तारीख और समय है. आम तौर पर, बाद वाले नोटेशन का इस्तेमाल किया जाता है.

एपीआई प्रॉडक्ट कॉन्फ़िगरेशन से कोटा सेटिंग हासिल करना

आपके पास एपीआई प्रॉडक्ट कॉन्फ़िगरेशन में कोटा सीमाएं सेट करने का विकल्प है. ये सीमाएं अपने-आप कोटा लागू नहीं होती हैं. इसके बजाय, आप कोटा नीति में प्रॉडक्ट कोटा सेटिंग का रेफ़रंस दे सकते हैं. कोटा से जुड़ी नीतियों का रेफ़रंस देने के लिए, प्रॉडक्ट पर कोटा सेट करने के कुछ फ़ायदे यहां बताए गए हैं:

  • कोटा नीतियां, एपीआई प्रॉडक्ट में सभी एपीआई प्रॉक्सी में एक जैसी सेटिंग का इस्तेमाल कर सकती हैं.
  • किसी एपीआई प्रॉडक्ट की कोटा सेटिंग में रनटाइम में बदलाव किए जा सकते हैं. साथ ही, वैल्यू का रेफ़रंस देने वाली कोटा नीतियों में, अपने-आप अपडेट की गई कोटा वैल्यू होती हैं.

एपीआई प्रॉडक्ट की कोटा सेटिंग का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, ऊपर दिया गया "डाइनैमिक कोटा" वाला उदाहरण देखें..

कोटा की सीमाओं के साथ एपीआई प्रॉडक्ट कॉन्फ़िगर करने के बारे में जानने के लिए, एपीआई प्रॉडक्ट बनाना लेख पढ़ें.

एलिमेंट का रेफ़रंस

यहां ऐसे एलिमेंट और एट्रिब्यूट दिए गए हैं जिन्हें इस नीति पर कॉन्फ़िगर किया जा सकता है. ध्यान दें कि कुछ एलिमेंट के कॉम्बिनेशन, म्युचुअली एक्सक्लूसिव होते हैं या उनकी ज़रूरत नहीं होती. खास इस्तेमाल के लिए सैंपल देखें. नीचे दिए गए verifyapikey.VerifyAPIKey.apiproduct.* वैरिएबल, डिफ़ॉल्ट रूप से तब उपलब्ध होते हैं, जब अनुरोध में ऐप्लिकेशन के एपीआई पासकोड की जांच करने के लिए, "VerifyAPIKey" नाम की पुष्टि करने की नीति का इस्तेमाल किया जाता है. वैरिएबल वैल्यू, एपीआई प्रॉडक्ट की कोटा सेटिंग से मिलती हैं. इसकी जानकारी, एपीआई प्रॉडक्ट कॉन्फ़िगरेशन से कोटा सेटिंग पाना में दी गई है.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> 
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime> 
   <Distributed>false</Distributed> 
   <Synchronous>false</Synchronous> 
   <AsynchronousConfiguration> 
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds> 
      <SyncMessageCount>5</SyncMessageCount> 
   </AsynchronousConfiguration> 
   <Identifier/> 
   <MessageWeight/> 
</Quota>

<कोटा> एट्रिब्यूट

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

ये एट्रिब्यूट इस नीति के लिए खास हैं.

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
टाइप करें

इसका इस्तेमाल यह तय करने के लिए करें कि कोटा काउंटर, कोटा के इस्तेमाल की जांच कब और कैसे करता है. ज़्यादा जानकारी के लिए, कोटा से जुड़ी नीति के टाइप देखें.

अगर आपने type की कोई वैल्यू छोड़ी है, तो काउंटर की शुरुआत मिनट/घंटा/दिन/हफ़्ते/महीने की शुरुआत से होगी.

मान्य वैल्यू में ये शामिल हैं:

  • calendar: तय समय के हिसाब से कोटा कॉन्फ़िगर करें. हर ऐप्लिकेशन के लिए कोटा काउंटर को, आपकी सेट की गई <StartTime>, <Interval>, और <TimeUnit> वैल्यू के आधार पर रीफ़्रेश किया जाता है.
  • rollingwindow: ऐसा कोटा कॉन्फ़िगर करें जो कोटा का इस्तेमाल तय करने के लिए, "रोलिंग विंडो" का इस्तेमाल करता है. rollingwindow में, <Interval> और <TimeUnit> एलिमेंट का इस्तेमाल करके विंडो का साइज़ तय किया जाता है. उदाहरण के लिए, एक दिन. जब कोई अनुरोध मिलता है, तो Edge, अनुरोध किए जाने के सटीक समय (जैसे कि शाम 5:01 बजे) देखता है. वह पिछले दिन (एक दिन) और इससे पहले के समय पर मिले अनुरोधों की संख्या गिनता है. साथ ही, यह भी देखता है कि इस विंडो में कोटा पार हुआ है या नहीं.
  • flexi: वह कोटा कॉन्फ़िगर करें जो किसी ऐप्लिकेशन से पहला अनुरोध मैसेज मिलने पर काउंटर शुरू करता है. साथ ही, यह <Interval>, और <TimeUnit> वैल्यू के आधार पर रीसेट होता है.
कैलेंडर ज़रूरी नहीं

इस टेबल में उन एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट के लिए एक जैसे होते हैं:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
name

नीति का अंदरूनी नाम. name एट्रिब्यूट की वैल्यू में अक्षर, संख्याएं, स्पेस, हाइफ़न, अंडरस्कोर, और पीरियड शामिल किए जा सकते हैं. इस वैल्यू में 255 से ज़्यादा वर्ण नहीं हो सकते.

इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को आम भाषा में अलग नाम से लेबल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल करें.

लागू नहीं ज़रूरी है
continueOnError

इस नीति को false पर सेट करें, ताकि नीति के काम न करने पर गड़बड़ी का मैसेज दिखे. ज़्यादातर नीतियों में, ऐसा आम तौर पर किया जाता है.

किसी नीति के काम न करने पर भी फ़्लो एक्ज़ीक्यूट करने की प्रोसेस को जारी रखने के लिए, true पर सेट करें.

false ज़रूरी नहीं
enabled

नीति लागू करने के लिए, true पर सेट करें.

नीति को बंद करने के लिए, false पर सेट करें. अगर यह नीति किसी फ़्लो से जुड़ी हुई है, तब भी उसे लागू नहीं किया जाएगा.

सही ज़रूरी नहीं
async

यह एट्रिब्यूट अब काम नहीं करता.

false बहिष्कृत

<DisplayName> एलिमेंट

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, आम भाषा के अलग नाम से नीति को लेबल करने के लिए, name एट्रिब्यूट का इस्तेमाल करें.

<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट

लागू नहीं

अगर इस एलिमेंट को छोड़ दिया जाता है, तो नीति के name एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है.

मौजूदगी ज़रूरी नहीं
Type String

<Allow> एलिमेंट

इससे कोटे की संख्या की सीमा का पता चलता है. अगर नीति का काउंटर इस सीमा तक पहुंच जाता है, तो काउंटर रीसेट होने तक बाद के कॉल अस्वीकार कर दिए जाते हैं.

<Allow> एलिमेंट को सेट करने के तीन तरीके यहां दिए गए हैं:

<Allow count="2000"/> 
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

count और countRef, दोनों को शामिल करने पर countRef को प्राथमिकता मिलती है. अगर रनटाइम के दौरान countRef का समाधान नहीं होता है, तो count की वैल्यू का इस्तेमाल किया जाता है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप: पूर्णांक

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
सोलर पैनलों की संख्या

कोटा के लिए मैसेज की संख्या तय करने के लिए इस्तेमाल करें.

जैसे, count एट्रिब्यूट की 100 वैल्यू, एक का Interval, और महीने का TimeUnit तय करने के लिए, हर महीने 100 मैसेज का कोटा तय होता है.

2,000 ज़रूरी नहीं
countRef

एक ऐसा फ़्लो वैरिएबल तय करने के लिए इस्तेमाल करें जिसमें किसी कोटे के लिए मैसेज की संख्या शामिल हो. countRef को count एट्रिब्यूट के ऊपर प्राथमिकता दी जाती है.

कुछ नहीं ज़रूरी नहीं

<Allow>/<Class> एलिमेंट

<Class> एलिमेंट की मदद से, फ़्लो वैरिएबल की वैल्यू के आधार पर, <Allow> एलिमेंट की वैल्यू को कंडीशनलाइज़ किया जा सकता है. <Class> के हर अलग <Allow> चाइल्ड टैग के लिए, नीति में अलग काउंटर तय किया गया है.

<Class> एलिमेंट का इस्तेमाल करने के लिए, <Class> टैग के लिए ref एट्रिब्यूट का इस्तेमाल करके एक फ़्लो वैरिएबल तय करें. इसके बाद, Edge फ़्लो वैरिएबल की वैल्यू का इस्तेमाल करके, <Allow> चाइल्ड टैग में से किसी एक को चुनता है, ताकि यह तय किया जा सके कि नीति को लागू करने की अनुमति है या नहीं. एज, फ़्लो वैरिएबल की वैल्यू को <Allow> टैग के class एट्रिब्यूट से मैच करता है, जैसा कि यहां दिखाया गया है:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

इस उदाहरण में, मौजूदा कोटा काउंटर को हर अनुरोध के साथ पास किए गए time_variable क्वेरी पैरामीटर की वैल्यू से तय किया जाता है. उस वैरिएबल की वैल्यू peak_time या off_peak_time हो सकती है. अगर क्वेरी पैरामीटर में कोई अमान्य वैल्यू है, तो नीति के तहत कोटा के उल्लंघन से जुड़ी गड़बड़ी दिखती है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप: लागू नहीं

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
संदर्भ

किसी कोटा के लिए कोटा क्लास वाला फ़्लो वैरिएबल तय करने के लिए इसका इस्तेमाल करें.

कुछ नहीं ज़रूरी है

<Allow>/<Class>/<Allow> एलिमेंट

<Allow> एलिमेंट, <Class> एलिमेंट से तय किए गए कोटा काउंटर की सीमा तय करता है. <Class> के हर अलग <Allow> चाइल्ड टैग के लिए, इस नीति के तहत एक अलग काउंटर तय किया गया है.

उदाहरण के लिए:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

इस उदाहरण में, कोटा नीति के तहत peak_time और off_peak_time नाम के दो कोटा काउंटर बनाए गए हैं.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप: लागू नहीं

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
क्लास

कोटा काउंटर का नाम तय करता है.

कुछ नहीं ज़रूरी है
सोलर पैनलों की संख्या काउंटर के लिए कोटा की सीमा की जानकारी देता है. कुछ नहीं ज़रूरी है

<Interval> एलिमेंट

1, 2, 5, 60 वगैरह जैसे किसी पूर्णांक (जैसे कि 1, 2, 5, 60 वगैरह) को तय करने के लिए इस्तेमाल करें जिसे आपके बताए गए TimeUnit (मिनट, घंटा, दिन, हफ़्ता या महीना) के साथ जोड़ा जाएगा. ऐसा करके, ऐसी समयावधि तय की जाती है जिसके दौरान Edge का इस्तेमाल कोटा का हिसाब किया जाता है.

उदाहरण के लिए, hour के TimeUnit के साथ 24 के Interval का मतलब है कि 24 घंटे के दौरान कोटा का हिसाब लगाया जाएगा.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
डिफ़ॉल्ट: कुछ नहीं
मौजूदगी: ज़रूरी है
टाइप: पूर्णांक

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
संदर्भ

एक ऐसा फ़्लो वैरिएबल तय करने के लिए इस्तेमाल करें जिसमें कोटे के लिए इंटरवल हो. ref को तय इंटरवल की वैल्यू के ऊपर प्राथमिकता दी जाती है. अगर रेफ़रंस और वैल्यू, दोनों के बारे में बताया जाता है, तो रेफ़रंस को प्राथमिकता दी जाती है. अगर रनटाइम के दौरान ref की समस्या हल नहीं होती है, तो वैल्यू का इस्तेमाल किया जाता है.

कुछ नहीं ज़रूरी नहीं

<TimeUnit> एलिमेंट

कोटे के लिए लागू समय की इकाई बताने के लिए इसका इस्तेमाल करें.

उदाहरण के लिए, hour के TimeUnit के साथ 24 के Interval का मतलब है कि 24 घंटे के दौरान कोटा का हिसाब लगाया जाएगा.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
डिफ़ॉल्ट: कुछ नहीं
मौजूदगी: ज़रूरी है
टाइप:

स्ट्रिंग. minute, hour, day, week या month में से चुनें.

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
संदर्भ किसी ऐसे फ़्लो वैरिएबल को तय करने के लिए इस्तेमाल करें जिसमें कोटा के लिए समय की इकाई शामिल हो. ref को तय इंटरवल की वैल्यू के बजाय प्राथमिकता दी जाती है. अगर ref, रनटाइम के दौरान ठीक नहीं होती है, तो वैल्यू का इस्तेमाल किया जाता है. कुछ नहीं ज़रूरी नहीं

<StartTime> एलिमेंट

जब type को calendar, पर सेट किया जाता है, तो यह उस तारीख और समय के बारे में बताता है जब कोटा काउंटर गिनती शुरू करेगा. इस बात से कोई फ़र्क़ नहीं पड़ता कि किसी ऐप्लिकेशन से कोई अनुरोध मिला है या नहीं.

अगर type को साफ़ तौर पर calendar, पर सेट किया गया है, तो आपको StartTime के बारे में साफ़ तौर पर बताना होगा. आप किसी फ़्लो वैरिएबल के रेफ़रंस का इस्तेमाल नहीं कर सकते. अगर कोई type वैल्यू सेट न होने पर, StartTime की वैल्यू दी जाए, तो आपको गड़बड़ी का मैसेज मिलेगा.

उदाहरण के लिए:

<StartTime>2017-7-16 12:00:00</StartTime>
डिफ़ॉल्ट: कुछ नहीं
मौजूदगी: जब type को calendar पर सेट किया जाता है, तब इसे भरना ज़रूरी है.
टाइप:

स्ट्रिंग, ISO 8601 तारीख और समय के फ़ॉर्मैट में होनी चाहिए.

<डिस्ट्रिब्यूट किया गया> एलिमेंट

Edge को इंस्टॉल करने पर अनुरोधों को प्रोसेस करने के लिए, एक या एक से ज़्यादा मैसेज प्रोसेसर इस्तेमाल किए जा सकते हैं. इस एलिमेंट को true पर सेट करें, ताकि यह बताया जा सके कि नीति को एक मुख्य काउंटर बनाए रखना चाहिए और इसे सभी मैसेज प्रोसेसर के बीच लगातार सिंक करना चाहिए. मैसेज प्रोसेस करने वाली कंपनियां, उपलब्धता ज़ोन और/या क्षेत्रों में हो सकती हैं.

अगर false की डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है, तो आपका कोटा पार हो सकता है. ऐसा इसलिए, क्योंकि हर मैसेज प्रोसेसर की संख्या शेयर नहीं की जाती:

<Distributed>true</Distributed>

इस बात की गारंटी देने के लिए कि काउंटर सिंक किए गए हैं और हर अनुरोध पर अपडेट किए गए हैं, <Distributed> और <Synchronous> को 'सही है' पर सेट करें:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>
डिफ़ॉल्ट: false
मौजूदगी: ज़रूरी नहीं
टाइप: बूलियन

<सिंक्रोनस> एलिमेंट

डिस्ट्रिब्यूटेड कोटा काउंटर को सिंक करने के साथ-साथ अपडेट करने के लिए, true पर सेट करें. इसका मतलब है कि काउंटर में उसी समय अपडेट किए जाते हैं, जब एपीआई से अनुरोध करने पर कोटा की जांच की जाती है. अगर यह ज़रूरी है कि आप कोटा से ज़्यादा एपीआई कॉल की अनुमति न दें, तो इसे true पर सेट करें.

एसिंक्रोनस तरीके से कोटा काउंटर अपडेट करने के लिए, false पर सेट करें. इसका मतलब है कि हो सकता है कि कुछ एपीआई कॉल, कोटा से ज़्यादा हो जाएं. यह इस बात पर निर्भर करता है कि सेंट्रल रिपॉज़िटरी में, कोटा काउंटर को एसिंक्रोनस रूप से कब अपडेट किया गया है. हालांकि, आपको सिंक्रोनस अपडेट से जुड़े परफ़ॉर्मेंस पर पड़ने वाले संभावित असर का सामना नहीं करना पड़ेगा.

डिफ़ॉल्ट एसिंक्रोनस अपडेट अंतराल 10 सेकंड है. इस एसिंक्रोनस व्यवहार को कॉन्फ़िगर करने के लिए AsynchronousConfiguration एलिमेंट का इस्तेमाल करें.

<Synchronous>false</Synchronous>
डिफ़ॉल्ट: false
मौजूदगी: ज़रूरी नहीं
टाइप: बूलियन

<AsynchronousConfiguration> एलिमेंट

यह नीति, डिस्ट्रिब्यूट किए गए कोटा काउंटर के बीच सिंक करने के इंटरवल को तब कॉन्फ़िगर करती है, जब नीति का कॉन्फ़िगरेशन एलिमेंट <Synchronous> मौजूद न हो या वह मौजूद न हो और false पर सेट हो.

SyncIntervalInSeconds या SyncMessageCount चाइल्ड एलिमेंट का इस्तेमाल करके, किसी तय समयावधि या मैसेज की संख्या के बाद सिंक किया जा सकता है. ये दोनों खास होते हैं. उदाहरण के लिए,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

या

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>
डिफ़ॉल्ट: सिंकइंटरवल इनसेकंड = 10 सेकंड
मौजूदगी: ज़रूरी नहीं; जब <Synchronous> को true पर सेट किया जाता है, तो इसे अनदेखा किया जाता है.
टाइप:

परिसर

<AsynchronousConfiguration>/<SyncIntervalInSeconds> एलिमेंट

इसका इस्तेमाल डिफ़ॉल्ट व्यवहार को बदलने के लिए करें, जिसमें 10 सेकंड के अंतराल के बाद एसिंक्रोनस अपडेट किए जाते हैं.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

सिंक का इंटरवल >= 10 सेकंड का होना चाहिए, जैसा कि सीमाएं विषय में बताया गया है.

डिफ़ॉल्ट: 10
मौजूदगी: ज़रूरी नहीं
टाइप:

पूर्णांक

<AsynchronousConfiguration>/<SyncMessageCount> एलिमेंट

इससे यह तय होता है कि कोटे को अपडेट करने के बीच, सभी Apigee मैसेज प्रोसेसर के अनुरोधों की संख्या कितनी होगी.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

इस उदाहरण से पता चलता है कि हर Apigee Edge मैसेज प्रोसेसर पर, हर पांच अनुरोध के बाद कोटा की संख्या अपडेट होती है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप:

पूर्णांक

<आइडेंटिफ़ायर> एलिमेंट

फ़्लो वैरिएबल के आधार पर यूनीक काउंटर बनाने के लिए, नीति को कॉन्फ़िगर करने के लिए <Identifier> एलिमेंट का इस्तेमाल करें.

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

अगर इस एलिमेंट का इस्तेमाल नहीं किया जाता है, तो नीति एक काउंटर का इस्तेमाल करती है, जिसे कोटा पर लागू किया जाता है.

इस एलिमेंट के बारे में Apigee कम्यूनिटी पोस्ट में भी बताया गया है: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>
डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप:

स्ट्रिंग

एट्रिब्यूट

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
संदर्भ

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

ऐप्लिकेशन की खास तरह से पहचान करने के लिए, आम तौर पर client_id <Identifier> का इस्तेमाल किया जाता है. एपीआई पासकोड या उपभोक्ता कुंजी का दूसरा नाम client_id भी होता है. यह किसी ऐप्लिकेशन के लिए तब जनरेट होता है, जब उसे Apigee Edge पर किसी संगठन में रजिस्टर किया जाता है. अगर आपने अपने एपीआई के लिए, एपीआई पासकोड या OAuth अनुमति देने से जुड़ी नीतियां चालू की हैं, तो इस आइडेंटिफ़ायर का इस्तेमाल किया जा सकता है.

कुछ मामलों में, कोटा सेटिंग फिर से हासिल की जानी चाहिए जहां client_id उपलब्ध नहीं है. जैसे, जब कोई सुरक्षा नीति लागू न हो. ऐसे मामलों में, एपीआई प्रॉडक्ट की सही सेटिंग को फिर से पाने के लिए, ऐक्सेस एंटिटी नीति का इस्तेमाल किया जा सकता है. इसके बाद, ExtractVariables का इस्तेमाल करके वैल्यू एक्सट्रैक्ट की जा सकती हैं. इसके बाद, कोटा नीति में एक्सट्रैक्ट किए गए कॉन्टेक्स्ट वैरिएबल का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, ऐक्सेस इकाई की नीति देखें.

लागू नहीं ज़रूरी नहीं

<MessageWeight> एलिमेंट

हर मैसेज को असाइन किए गए वज़न को बताने के लिए इसका इस्तेमाल करें. अनुरोध वाले मैसेज के असर को बढ़ाने के लिए, मैसेज के महत्व का इस्तेमाल करें. उदाहरण के लिए, वे मैसेज जो दूसरों के मुकाबले ज़्यादा कंप्यूटेशनल संसाधनों का इस्तेमाल करते हैं.

उदाहरण के लिए, आपको पोस्ट मैसेज की गिनती "बहुत ज़्यादा" या महंगी के तौर पर, GET मैसेज के तौर पर दोगुनी करनी है. इसलिए, पीओएसटी के लिए MessageWeight को 2 और जीईटी के लिए 1 पर सेट किया जाता है. MessageWeight को 0 पर भी सेट किया जा सकता है, ताकि अनुरोध का असर न हो. इस उदाहरण में, अगर कोटा, 10 मैसेज प्रति मिनट और पोस्ट अनुरोधों के लिए MessageWeight 2 है, तो कोटा किसी भी 10 मिनट के अंतराल में पांच पोस्ट अनुरोधों को अनुमति देगा. काउंटर रीसेट को अस्वीकार किए जाने से पहले, कोई भी अतिरिक्त अनुरोध, जैसे कि POST या GET.

MessageWeight को दिखाने वाली वैल्यू, किसी फ़्लो वैरिएबल से तय होनी चाहिए. साथ ही, इसे एचटीटीपी हेडर, क्वेरी पैरामीटर, एक्सएमएल या JSON अनुरोध पेलोड या किसी अन्य फ़्लो वैरिएबल से निकाला जा सकता है. उदाहरण के लिए, आपने इसे weight नाम के हेडर में सेट किया है:

<MessageWeight ref="message_weight"/>
डिफ़ॉल्ट: लागू नहीं
मौजूदगी: ज़रूरी नहीं
टाइप:

पूर्णांक

फ़्लो वैरिएबल

कोटा नीति के लागू होने पर, पहले से तय किए गए इन फ़्लो वैरिएबल की जानकारी अपने-आप भर जाती है. फ़्लो वैरिएबल के बारे में ज़्यादा जानकारी के लिए, वैरिएबल रेफ़रंस देखें.

वैरिएबल टाइप अनुमतियां ब्यौरा
ratelimit.{policy_name}.allowed.count ज़्यादा समय के लिए रीड-ओनली मंज़ूर किए गए कोटा की संख्या दिखाता है
ratelimit.{policy_name}.used.count ज़्यादा समय के लिए रीड-ओनली कोटा इंटरवल में इस्तेमाल किए गए मौजूदा कोटा को लौटाता है
ratelimit.{policy_name}.available.count ज़्यादा समय के लिए रीड-ओनली कोटा इंटरवल में उपलब्ध कोटे की संख्या दिखाता है
ratelimit.{policy_name}.exceed.count ज़्यादा समय के लिए रीड-ओनली कोटा खत्म होने के बाद, 1 वैल्यू मिलती है.
ratelimit.{policy_name}.total.exceed.count ज़्यादा समय के लिए रीड-ओनली कोटा खत्म होने के बाद, 1 वैल्यू मिलती है.
ratelimit.{policy_name}.expiry.time ज़्यादा समय के लिए रीड-ओनली

मिलीसेकंड में यूटीसी समय की जानकारी देता है. इससे यह तय होता है कि कोटा कब खत्म होगा और नया कोटा कब शुरू होगा.

कोटा नीति का टाइप rollingwindow होने पर, यह वैल्यू मान्य नहीं होती. इसकी वजह यह है कि कोटा इंटरवल की समयसीमा कभी खत्म नहीं होती.

ratelimit.{policy_name}.identifier स्ट्रिंग रीड-ओनली नीति से अटैच किए गए (क्लाइंट) आइडेंटिफ़ायर का रेफ़रंस दिखाता है
ratelimit.{policy_name}.class स्ट्रिंग रीड-ओनली क्लाइंट आइडेंटिफ़ायर से जुड़ी क्लास दिखाता है
ratelimit.{policy_name}.class.allowed.count ज़्यादा समय के लिए रीड-ओनली यह फ़ंक्शन क्लास में तय किए गए कोटा की संख्या दिखाता है
ratelimit.{policy_name}.class.used.count ज़्यादा समय के लिए रीड-ओनली किसी क्लास में इस्तेमाल किया गया कोटा दिखाता है
ratelimit.{policy_name}.class.available.count ज़्यादा समय के लिए रीड-ओनली क्लास में उपलब्ध कोटा की संख्या दिखाता है
ratelimit.{policy_name}.class.exceed.count ज़्यादा समय के लिए रीड-ओनली ऐसे अनुरोधों की संख्या दिखाता है जो मौजूदा कोटा इंटरवल में क्लास की तय सीमा से ज़्यादा हैं
ratelimit.{policy_name}.class.total.exceed.count ज़्यादा समय के लिए रीड-ओनली यह फ़ंक्शन ऐसे अनुरोधों की कुल संख्या दिखाता है जो क्लास में सभी कोटा इंटरवल के लिए तय सीमा से ज़्यादा होते हैं. इसलिए, यह सभी कोटा इंटरवल के लिए class.exceed.count का कुल योग होता है.
ratelimit.{policy_name}.failed बूलियन रीड-ओनली

इससे पता चलता है कि नीति पूरी हुई या नहीं (सही या गलत).

गड़बड़ी का रेफ़रंस

यह सेक्शन गड़बड़ी के कोड और दिखाए गए गड़बड़ी के मैसेज के बारे में बताता है. साथ ही, इस नीति के ट्रिगर होने पर Edge की मदद से सेट की गई गड़बड़ी के वैरिएबल के बारे में बताता है. यह जानकारी जानना ज़रूरी है कि क्या गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.

रनटाइम से जुड़ी गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

गड़बड़ी का कोड एचटीटीपी कोड स्थिति वजह समाधान
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 ऐसा तब होता है, जब कोटा नीति में <Interval> एलिमेंट के बारे में नहीं बताया गया हो. यह एलिमेंट ज़रूरी है. इसका इस्तेमाल, कोटे पर लागू होने वाले समय का अंतराल बताने के लिए किया जाता है. समय इंटरवल के तौर पर <TimeUnit> एलिमेंट के मुताबिक मिनट, घंटे, दिन, हफ़्ते या महीने हो सकता है.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 ऐसा तब होता है, जब कोटा नीति में <TimeUnit> एलिमेंट के बारे में नहीं बताया गया हो. यह एलिमेंट ज़रूरी है. इसका इस्तेमाल, कोटा के लिए लागू होने वाले समय की इकाई बताने के लिए किया जाता है. समय अंतराल मिनट, घंटों, दिन, हफ़्तों या महीनों में हो सकता है.
policies.ratelimit.InvalidMessageWeight 500 ऐसा तब होता है, जब फ़्लो वैरिएबल के ज़रिए तय की गई <MessageWeight> एलिमेंट की वैल्यू अमान्य हो (एक अमान्य वैल्यू).
policies.ratelimit.QuotaViolation 500 इससे ज़्यादा इस्तेमाल नहीं किया जा सकता. लागू नहीं

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

गड़बड़ी का नाम वजह समाधान
InvalidQuotaInterval अगर <Interval> एलिमेंट में दिया गया कोटा इंटरवल पूर्णांक नहीं है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. उदाहरण के लिए, अगर <Interval> एलिमेंट में तय किया गया कोटा इंटरवल 0.1 है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.
InvalidQuotaTimeUnit अगर <TimeUnit> एलिमेंट में दी गई समय की यूनिट काम नहीं करती है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. समय की इकाइयों का इस्तेमाल किया जा सकता है: minute, hour, day, week, और month.
InvalidQuotaType अगर <Quota> एलिमेंट में type एट्रिब्यूट में दिया गया कोटा अमान्य है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. default, calendar, flexi, और rollingwindow इस्तेमाल किए जा सकते हैं.
InvalidStartTime अगर <StartTime> एलिमेंट में दिए गए समय का फ़ॉर्मैट अमान्य है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. मान्य फ़ॉर्मैट yyyy-MM-dd HH:mm:ss है, जो ISO 8601 तारीख और समय फ़ॉर्मैट है. उदाहरण के लिए, अगर <StartTime> एलिमेंट में दिया गया समय 7-16-2017 12:00:00 है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.
StartTimeNotSupported अगर <StartTime> एलिमेंट के बारे में बताया गया है, जिसका कोटा टाइप calendar टाइप नहीं है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. <StartTime> एलिमेंट, सिर्फ़ calendar तरह के कोटा के लिए काम करता है. उदाहरण के लिए, अगर <Quota> एलिमेंट में type एट्रिब्यूट को flexi या rolling window पर सेट किया गया है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.
InvalidTimeUnitForDistributedQuota अगर <Distributed> एलिमेंट को true पर सेट किया गया है और <TimeUnit> एलिमेंट को second पर सेट किया गया है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. दिए गए कोटा के लिए समय इकाई second अमान्य है.
InvalidSynchronizeIntervalForAsyncConfiguration अगर कोटा नीति के <AsynchronousConfiguration> एलिमेंट में <SyncIntervalInSeconds> एलिमेंट के लिए तय की गई वैल्यू शून्य से कम है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.
InvalidAsynchronizeConfigurationForSynchronousQuota अगर कोटा नीति में <AsynchronousConfiguration> एलिमेंट की वैल्यू true पर सेट की गई है, जिसमें <AsynchronousConfiguration> एलिमेंट का इस्तेमाल करके एसिंक्रोनस कॉन्फ़िगरेशन भी तय किया गया है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.

गड़बड़ी वाले वैरिएबल

ये वैरिएबल तब सेट किए जाते हैं, जब इस नीति से कोई गड़बड़ी ट्रिगर होती है. ज़्यादा जानकारी के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी देखें.

वैरिएबल जगह उदाहरण
fault.name="fault_name" fault_name, गड़बड़ी का नाम है, जैसा कि ऊपर रनटाइम की गड़बड़ियां टेबल में दिया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. fault.name Matches "QuotaViolation"
ratelimit.policy_name.failed policy_name, उस नीति का उपयोगकर्ता तय किया गया नाम है जिसकी वजह से गड़बड़ी हुई है. ratelimit.QT-QuotaPolicy.failed = true

गड़बड़ी के जवाब का उदाहरण

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

गड़बड़ी के नियम का उदाहरण

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

स्कीमा

मिलते-जुलते विषय

ResetDefault की नीति

SpikeArrest की नीति

कोटा, स्पाइक अरेस्ट, और एक ही समय पर दर की सीमा से जुड़ी नीतियों की तुलना करना