इस्तेमाल करने की सीमाएं और कोटा

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

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

अगर आपके अनुरोधों को तय समय में पूरा करना है, तो अपने अनुरोधों को एक साथ भेजें या अपने Java या C# ऐप्लिकेशन में एक से ज़्यादा थ्रेड का इस्तेमाल करें. समानांतर अनुरोधों का एक उदाहरण यह है कि एक साथ किसी एक उपयोगकर्ता के कई ईमेल पते जोड़ने या हटाने के बजाय, अलग-अलग उपयोगकर्ताओं से ईमेल पतों के छोटे बैच का अनुरोध करना. थ्रेड के मामले में, 10 थ्रेड से शुरुआत करें. हर उपयोगकर्ता के ईमेल के लिए एक थ्रेड बनाएं. ध्यान दें कि थ्रेड के सुझाव के कुछ फ़ायदे और कुछ नुकसान हैं. साथ ही, यह एपीआई से जुड़ी सभी स्थितियों के लिए काम का नहीं है. अगर अनुरोधों की संख्या बहुत ज़्यादा हो जाती है, तो कोटे से जुड़ी गड़बड़ियां दिखती हैं. ट्रेड-ऑफ़ का एक और उदाहरण, ईमेल ऑडिट एपीआई का कोटा है. यह कोटा, मैसेज अपलोड करने की ज़्यादा से ज़्यादा दर के लिए होता है. अपलोड करने की दर, हर उपयोगकर्ता के लिए हर सेकंड में एक एपीआई अनुरोध है. इससे कोई फ़र्क़ नहीं पड़ता कि अपलोड करने के अनुरोध कितनी थ्रेड कर रही हैं.

समय पर आधारित सभी गड़बड़ियों (हर थ्रेड के लिए N सेकंड में ज़्यादा से ज़्यादा N चीज़ें) के लिए, हमारा सुझाव है कि आपका कोड अपवाद को पकड़ ले. साथ ही, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, कॉल को फिर से आज़माने से पहले कुछ समय इंतज़ार करे. खास तौर पर, 503 स्टेटस कोड से जुड़ी गड़बड़ियों के लिए ऐसा करें. एक थ्रेड के लिए, ईमेल ऑडिट एपीआई का उदाहरण यह है कि पांच सेकंड इंतज़ार करें और पूरे न हो पाने वाले कॉल को फिर से आज़माएं. अगर अनुरोध पूरा हो जाता है, तो अन्य थ्रेड के लिए भी इसी पैटर्न को दोहराएं. अगर दूसरा अनुरोध पूरा नहीं होता है, तो आपके ऐप्लिकेशन को अनुरोध की फ़्रीक्वेंसी को तब तक कम करना चाहिए, जब तक कॉल पूरा न हो जाए. उदाहरण के लिए, शुरुआती पांच सेकंड की देरी को बढ़ाकर 10 सेकंड करें. इसके बाद, कॉल करने की कोशिश फिर से करें. इसके अलावा, फिर से कोशिश करने की सीमा भी तय करें. उदाहरण के लिए, अपने ऐप्लिकेशन में उपयोगकर्ता को गड़बड़ी का मैसेज दिखाने से पहले, अनुरोध को पांच से सात बार फिर से भेजें. हर बार अनुरोध भेजने के बीच कुछ समय का अंतर रखें.

यहां दी गई टेबल में, Email Audit API के लिए तय की गई सीमाएं दी गई हैं:

एपीआई की सीमाएं तय करने वाली कैटगरी	सीमाएं
एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें बनाना	एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें बनाने में, सिस्टम को कई दिन लग सकते हैं. यह समय, फ़ाइल के साइज़ पर निर्भर करता है.
एन्क्रिप्ट की गई मेलबॉक्स फ़ाइलें, मिटाने में गड़बड़ियां	एन्क्रिप्ट किए गए किसी मेलबॉक्स को मिटाते समय गड़बड़ियां होने पर, अनुरोध को MARKED_DELETE स्टेटस दिया जाता है. Google, इन खास जानकारी और एक्सपोर्ट की गई फ़ाइलों को 24 घंटे के अंदर फिर से मिटा देगा. ऐसा हो सकता है कि कुछ फ़ाइलें अब भी मौजूद हों. अगर MARKED_DELETE का स्टेटस लगातार दिखता है, तो घातांकीय बैक ऑफ़ रणनीति आज़माएं.

यहां दी गई टेबल में, Email Audit API के लिए तय किए गए कोटे दिए गए हैं:

एपीआई के कोटा की कैटगरी	कोटा
ClientLogin की मदद से पुष्टि करने वाले टोकन	यह 24 घंटे के लिए मान्य होता है. गड़बड़ी 401 token expired है.
तारीख फ़ॉर्मेट	ईमेल ऑडिट एपीआई के साथ इस्तेमाल करने से पहले, सभी तारीखों को कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी) फ़ॉर्मैट में बदलें. ज़्यादा जानकारी के लिए, यूटीसी कन्वर्टर देखें.
एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें, EXPIRED खास जानकारी, और एक्सपोर्ट की गई फ़ाइलें	Google, एन्क्रिप्ट की गई मेलबॉक्स फ़ाइलों को तीन हफ़्तों तक सेव रखता है. इसके बाद, उन्हें मिटा दिया जाता है. डोमेन एडमिन की यह ज़िम्मेदारी है कि वह इस समयावधि में, इन मेलबॉक्स फ़ाइलों को डाउनलोड करे.
एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें, फ़ॉर्मैट	एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें, mbox फ़ॉर्मैट में होती हैं.
एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइलें, ज़्यादा से ज़्यादा बनाने के अनुरोध	हर दिन, ज़्यादा से ज़्यादा 100 अनुरोध किए जा सकते हैं. ये अनुरोध, डोमेन के सभी एडमिन कर सकते हैं.
एन्क्रिप्ट (सुरक्षित) की गई मेलबॉक्स फ़ाइल का स्टेटस, पेज नंबर के हिसाब से बांटना	सभी मेलबॉक्स के अनुरोधों की स्थिति का अनुरोध करने पर, जवाबों में बहुत ज़्यादा डेटा मिल सकता है. Email Audit API, इस डेटा को पेजों में बैच करता है. हर पेज में ज़्यादा से ज़्यादा 100 एंट्री होती हैं. साथ ही, link rel='next'टैग में मौजूद यूआरआई, नतीजों के अगले पेज पर ले जाता है. क्लाइंट ऐप्लिकेशन डेवलप करते समय, आपके कोड को इन अतिरिक्त नतीजों को मैनेज करना होगा.
ईमेल मॉनिटर	हर दिन, ईमेल मॉनिटर करने के ज़्यादा से ज़्यादा 1,500 अनुरोध किए जा सकते हैं. यह सीमा, डोमेन के लिए है. इसमें दिन भर में किसी भी एडमिन की ओर से किए गए सभी अनुरोध शामिल हैं.
सार्वजनिक कुंजी	Email Audit API में सिर्फ़ एक कुंजी का इस्तेमाल किया जा सकता है. सार्वजनिक पासकोड, GNU Privacy Guard (GPG) सॉफ़्टवेयर का इस्तेमाल करता है. यह PGP फ़ॉर्मैट में होती है और ASCII-एन्कोड की गई RSA एन्क्रिप्शन कुंजी होती है. सार्वजनिक कुंजी अपलोड करने से पहले, आपको उसे base64 से कोड में बदली गई स्ट्रिंग में बदलना होगा. सार्वजनिक पासकोड फ़ाइल को इस वर्णसेट के साथ पढ़ा जाना चाहिए: US-ASCII, (IANA ASCII के लिए वर्णसेट का पसंदीदा नाम).
खोजा जा रहा है	searchQuery और includeDeleted पैरामीटर, एक-दूसरे के साथ काम नहीं करते हैं. अगर includeDeleted="true", तो खोज क्वेरी नहीं की जा सकती.