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

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

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

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

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

नीचे दी गई टेबल में, ईमेल ऑडिट एपीआई की सीमाएं बताई गई हैं:

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

नीचे दी गई टेबल में, ईमेल ऑडिट एपीआई के कोटे की जानकारी दी गई है:

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