सीमाएं और कोटा, Google के इंफ़्रास्ट्रक्चर को अपने-आप काम करने वाली प्रोसेस से सुरक्षित रखते हैं. यह प्रोसेस, गलत तरीके से Reports API का इस्तेमाल करती है. किसी एपीआई से बहुत ज़्यादा अनुरोध, गलत टाइपिंग की वजह से हो सकते हैं. इसके अलावा, यह किसी ऐसे सिस्टम की वजह से भी हो सकता है जिसे बिना किसी परेशानी के एपीआई कॉल किया जा सकता हो. वजह चाहे जो हो, Google Workspace सिस्टम की पूरी परफ़ॉर्मेंस के लिए, किसी खास सोर्स से आने वाले ट्रैफ़िक को एक तय लेवल तक पहुंचने के बाद ब्लॉक करना ज़रूरी है. इससे यह पक्का होता है कि एक डेवलपर की कार्रवाई से पूरे समुदाय पर बुरा असर न पड़े.
अगर आपका एपीआई अनुरोध फ़ेल हो जाता है, तो आपको एचटीटीपी स्टेटस कोड मिलेगा. 403 वाले स्टेटस कोड में गलत इनपुट के बारे में गड़बड़ी की जानकारी है और 503 वाले एचटीटीपी स्टेटस कोड में गड़बड़ी की जानकारी है, जिससे पता चलता है कि कौनसा एपीआई कोटा पार हो गया है. इन रिस्पॉन्स की मदद से, आपका कस्टम ऐप्लिकेशन इन गड़बड़ियों का पता लगा सकता है और ज़रूरी कार्रवाई कर सकता है.
अगर आपके अनुरोधों को किसी तय समय में पूरा करना ज़रूरी हो, तो अपने अनुरोध साथ-साथ भेजें या अपने Java या C# ऐप्लिकेशन में एक से ज़्यादा थ्रेड का इस्तेमाल करें. पैरलल अनुरोधों का एक उदाहरण अलग-अलग उपयोगकर्ताओं से एक साथ बहुत सारे ईमेल जोड़ने या हटाने के बजाय अलग-अलग उपयोगकर्ताओं से ईमेल के छोटे बैच का अनुरोध करना है. थ्रेड के मामले में, 10 थ्रेड से शुरू करने की कोशिश करें. हर उपयोगकर्ता के ईमेल पर एक थ्रेड होनी चाहिए. ध्यान दें कि थ्रेड के सुझाव में कुछ सुविधाएं नहीं हैं और एपीआई के सभी मामलों के लिए यह काम का नहीं है. अगर अनुरोधों की संख्या बहुत ज़्यादा हो जाती है, तो कोटा से जुड़ी गड़बड़ियां होंगी.
समय के हिसाब से होने वाली सभी गड़बड़ियों (हर थ्रेड में ज़्यादा से ज़्यादा N सेकंड के लिए, ज़्यादा से ज़्यादा N चीज़ों), खास तौर पर 503 स्टेटस कोड की गड़बड़ियों के लिए, हमारा सुझाव है कि आप अपवाद का पता लगाएं. साथ ही, एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, असफल कॉल को फिर से प्रोसेस करने से पहले थोड़ी देर इंतज़ार करें. किसी थ्रेड के लिए Reports API का उदाहरण, पांच सेकंड तक इंतज़ार करना और फ़ेल हो चुके कॉल को फिर से कोशिश करना है. अगर अनुरोध पूरा हो जाता है, तो दूसरी थ्रेड के लिए भी इस पैटर्न को दोहराएं. अगर दूसरा अनुरोध पूरा नहीं होता है, तो आपके ऐप्लिकेशन को अनुरोध की फ़्रीक्वेंसी के हिसाब से तब तक स्केल करना चाहिए, जब तक कॉल पूरा नहीं हो जाता. उदाहरण के लिए, शुरुआती 5 सेकंड की देरी को 10 सेकंड तक बढ़ाएं और जो कॉल पूरा नहीं हो पाया उसे फिर से करके देखें. साथ ही, कोशिश करने की सीमा तय करें. उदाहरण के लिए, आपके ऐप्लिकेशन से उपयोगकर्ता को गड़बड़ी मिलने से पहले, देरी वाले अलग-अलग समय के साथ पांच से सात बार फिर से अनुरोध करें.
| एपीआई की सीमा की कैटगरी | सीमाएं |
|---|---|
| क्यूपीएस और क्यूपीडी दरों की जानकारी दें | एपीआई, आपके Google Cloud प्रोजेक्ट के लिए अनुरोधों की संख्या को सीमित करता है.
Google Cloud Console में सेट की गई डिफ़ॉल्ट वैल्यू, हर Google Cloud प्रोजेक्ट के हर उपयोगकर्ता के लिए 2,400 क्वेरी प्रति मिनट है.
अपने Google Cloud प्रोजेक्ट के एडमिन SDK API कोटा पेज पर जाकर, इस सीमा को बढ़ाया जा सकता है.
अगर ये सीमाएं पार हो जाती हैं, तो सर्वर, एचटीटीपी 503 स्टेटस कोड दिखाता है. अपने अनुरोधों की फिर से कोशिश करते समय एक्सपोनेन्शियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करें. |
| एपीआई कोटा कैटगरी | कोटा |
| ज़्यादा से ज़्यादा नतीजे | किसी एपीआई से मिले रिस्पॉन्स के हर पेज में मौजूद रिकॉर्ड की संख्या, 1 से 1,000 तक होती है. डिफ़ॉल्ट तौर पर, यह 1,000 रिकॉर्ड होते हैं. |
| अन्य तरह की सीमाएं | सीमाएं और दिशा-निर्देश |
|---|---|
| डेटा फ़ॉर्मैट, डिफ़ॉल्ट | डेटा का डिफ़ॉल्ट फ़ॉर्मैट JSON है. यह API, ऐटम फ़ॉर्मैट के साथ भी काम करता है. |
| बिना अनुमति वाले अनुरोध | Google, API को बिना अनुमति के भेजे गए अनुरोधों की अनुमति नहीं देता. अगर कोई ऑथराइज़ेशन टोकन नहीं दिया गया है, तो अनुरोध को बिना अनुमति के माना जाता है. ज़्यादा जानकारी के लिए, अनुरोध की अनुमति देना देखें. |
| चेतावनी वाले मैसेज |
|