कोटा नीति

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

क्या

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

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

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

वीडियो

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

परिचय (नया Edge)

शुरुआती जानकारी (क्लासिक Edge)

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

डिस्ट्रिब्यूटेड और सिंक करने वाला

मैसेज का वज़न

Calendar

रोलिंग विंडो

Flexi

शर्तों के साथ कोटा

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

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

सैंपल

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

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

<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 नाम की VerifyAPIKey नीति का इस्तेमाल करती है. इसके बाद, कोटा नीति, एपीआई प्रॉडक्ट पर सेट की गई कोटा वैल्यू पढ़ने के लिए, VerifyAPIKey नीति से फ़्लो वैरिएबल ऐक्सेस करती है. 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>

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

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

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

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

प्रारंभ समय

<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 बजे GMT से शुरू होती है और हर पांच घंटे में रीफ़्रेश होती है. इसलिए, अगला रीफ़्रेश 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: काउंटर रीसेट होने का यूटीसी समय.

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

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

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

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

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

इसके अलावा, एपीआई प्रॉक्सी में कोटा से जुड़ी कई नीतियां तय की जा सकती हैं. कोटा की हर नीति के लिए, नीति के 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"/>

अगर एपीआई कुंजी की पुष्टि करने के लिए, VerifyAPIKey नीति या OAuth टोकन के साथ OAuthV2 नीतियां इस्तेमाल की जाती हैं, तो एक ही कोटा नीति के लिए अलग-अलग काउंटर तय करने के लिए, एपीआई कुंजी या टोकन में मौजूद जानकारी का इस्तेमाल किया जा सकता है. उदाहरण के लिए, यहां दिया गया <Identifier> टैग, verify-api-key नाम की VerifyAPIKey नीति के 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 की मदद से ट्रैफ़िक में अचानक होने वाली बढ़ोतरी (या बर्स्ट) को रोका जा सकता है. ट्रैफ़िक में अचानक बढ़ोतरी, इस्तेमाल में अचानक हुई बढ़ोतरी, बग वाले क्लाइंट या नुकसान पहुंचाने वाले हमलों की वजह से हो सकती है. SpikeArrest के बारे में ज़्यादा जानकारी के लिए, SpikeArrest की नीति देखें.

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

कोटा नीति के टाइप

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

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

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

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

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

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

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

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

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

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

  • फ़्लो A को लागू किया जाता है -> MyQuotaPolicy लागू की जाती है और उसका काउंटर = 1
  • फ़्लो B को लागू किया जाता है -> MyQuotaPolicy को लागू किया जाता है और उसका काउंटर = 2
  • फ़्लो A को लागू किया जाता है -> MyQuotaPolicy को लागू किया जाता है और उसका काउंटर = 3
  • फ़्लो C को लागू किया जाता है -> MyQuotaPolicy को लागू किया जाता है और उसका काउंटर = 4
  • फ़्लो A को लागू किया जाता है -> MyQuotaPolicy को लागू किया जाता है और उसका काउंटर = 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.VerifyAPIKey.apiproduct.* वैरिएबल डिफ़ॉल्ट रूप से उपलब्ध होते हैं. वैरिएबल की वैल्यू, उस एपीआई प्रॉडक्ट की कोटा सेटिंग से मिलती हैं जिससे कुंजी जुड़ी है. इस बारे में एपीआई प्रॉडक्ट कॉन्फ़िगरेशन से कोटा सेटिंग पाना में बताया गया है.

<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> एट्रिब्यूट

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

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

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

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

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

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

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

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

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

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

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

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

किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए false पर सेट करें. यह उम्मीद है व्यवहार की जानकारी देने वाला डेटा.

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

 गलत वैकल्पिक
enabled

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

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

 सही वैकल्पिक
async

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

 गलत बहिष्कृत

&lt;DisplayName&gt; एलिमेंट

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

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

लागू नहीं

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

<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 की वैल्यू 1, और TimeUnit की वैल्यू महीने होने पर, हर महीने 100 मैसेज भेजने की सीमा तय होती है.

 2000 वैकल्पिक
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 हो सकती है. अगर क्वेरी पैरामीटर में अमान्य वैल्यू दी गई है, तो नीति कोटा के उल्लंघन की गड़बड़ी दिखाती है.

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

विशेषताएं

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

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

 कोई नहीं ज़रूरी है

<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 वगैरह) की जानकारी देने के लिए इस्तेमाल करें. इसे आपके बताए गए TimeUnit (मिनट, घंटा, दिन, हफ़्ता या महीना) के साथ जोड़ा जाएगा. इससे, उस समयावधि का पता चलेगा जिसके दौरान Edge, कोटा के इस्तेमाल का हिसाब लगाता है.

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

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

विशेषताएं

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

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

 कोई नहीं वैकल्पिक

<TimeUnit> एलिमेंट

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

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

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

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

विशेषताएं

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

<StartTime> एलिमेंट

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

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

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

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

<Distributed> एलिमेंट

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

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

<Distributed>true</Distributed>

यह पक्का करने के लिए कि काउंटर सिंक हो जाएं और हर अनुरोध पर अपडेट हो जाएं, <Distributed> और <Synchronous> को 'सही' पर सेट करें:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>
डिफ़ॉल्ट: गलत
मौजूदगी: वैकल्पिक
टाइप: बूलियन

<Synchronous> एलिमेंट

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

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

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

<Synchronous>false</Synchronous>
डिफ़ॉल्ट: गलत
मौजूदगी: वैकल्पिक
टाइप: बूलियन

<AsynchronousConfiguration> एलिमेंट

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

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

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

या

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

परिसर

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

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

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

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

डिफ़ॉल्ट: 10
मौजूदगी: वैकल्पिक
टाइप:

पूर्णांक

<AsynchronousConfiguration>/<SyncMessageCount> element

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

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

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

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

पूर्णांक

<Identifier> एलिमेंट

<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"/>
डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप:

स्ट्रिंग

विशेषताएं

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

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

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

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

 लागू नहीं वैकल्पिक

<MessageWeight> एलिमेंट

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

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

MessageWeight की वैल्यू, किसी फ़्लो वैरिएबल से तय की जानी चाहिए. इसे एचटीटीपी हेडर, क्वेरी पैरामीटर, एक्सएमएल या जेएसओएन अनुरोध पेलोड या किसी अन्य फ़्लो वैरिएबल से निकाला जा सकता है. उदाहरण के लिए, आपने इसे 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 कोटा टाइप के लिए काम करता है. उदाहरण के लिए, अगर type एट्रिब्यूट सेट है <Quota> एलिमेंट में, flexi या rolling window के लिए एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सका.
InvalidTimeUnitForDistributedQuota अगर <Distributed> एलिमेंट true पर सेट है और <TimeUnit> एलिमेंट second का इस्तेमाल करने पर, एपीआई प्रॉक्सी का डिप्लॉयमेंट नहीं हो पाता. इसके लिए समय इकाई second अमान्य है एक डिस्ट्रिब्यूट किया गया कोटा.
InvalidSynchronizeIntervalForAsyncConfiguration अगर इवेंट में <SyncIntervalInSeconds> एलिमेंट के लिए दी गई वैल्यू कोटा नीति में <AsynchronousConfiguration> एलिमेंट शून्य से कम है, तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सका.
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>

स्कीमा

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

ResetQuota की नीति

SpikeArrest की नीति

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