अपने सभी एपीआई अनुरोधों में क्रेडेंशियल शेयर करने से परफ़ॉर्मेंस बेहतर होती है. साथ ही, इससे बहुत ज़्यादा ओवरहेड नहीं होता. इस वजह से, रेट लिमिट से जुड़ी गड़बड़ियां हो सकती हैं. इस गाइड में OAuth2 क्रेडेंशियल मैनेजमेंट को ऑप्टिमाइज़ करने का तरीका बताया गया है, ताकि आपका ऐप्लिकेशन Google Ads API के साथ बेहतर तरीके से इंटरैक्ट कर सके.
क्रेडेंशियल शेयर करने की आपकी रणनीति इस बात पर निर्भर करेगी कि आपका ऐप्लिकेशन मल्टीथ्रेड या मल्टीप्रोसेस (या डिस्ट्रिब्यूट किया गया) है. हर प्रोसेस में एक से ज़्यादा प्रोसेस और मल्टीथ्रेड, दोनों सुविधाओं वाले ऐप्लिकेशन में दोनों रणनीतियां होनी चाहिए. ये रणनीतियां कई Google Ads खातों के लिए भी अपनाई जा सकती हैं.
मल्टीथ्रेड
हर सेशन या थ्रेड के ज़रिए बनाए गए उपयोगकर्ता को एक ही क्रेडेंशियल ऑब्जेक्ट का इस्तेमाल करना चाहिए. रेस की स्थितियों से बचने के लिए, ऐक्सेस टोकन को सिंक करके भी रीफ़्रेश किया जाना चाहिए.
हमारी क्लाइंट लाइब्रेरी यह पक्का करती हैं कि क्रेडेंशियल, थ्रेड-सुरक्षित ऑब्जेक्ट है. यह ऐक्सेस टोकन की समयसीमा खत्म होने पर, अपने-आप रीफ़्रेश होता है. हमारी हर क्लाइंट लाइब्रेरी में, क्रेडेंशियल वाला एक सेशन (या उपयोगकर्ता) ऑब्जेक्ट होता है जिसे वह कभी भी इस्तेमाल करता है. क्रेडेंशियल को थ्रेड के बीच शेयर करने के लिए, आपको एक ही क्रेडेंशियल का इस्तेमाल करके हर सेशन
बनाना है. उदाहरण के लिए, Java क्लाइंट लाइब्रेरी में, आपको एक Credential सिंगलटन बनाना होगा और उसे सभी सेशन में शेयर करना होगा.
मल्टीप्रोसेस या डिस्ट्रिब्यूटेड
मल्टीप्रोसेस या डिस्ट्रिब्यूटेड प्रोसेस के लिए, आपको क्रेडेंशियल शेयर करने से पहले उसे सेव रखना होगा. यह पक्का करने के लिए कि कई प्रोसेस या सर्वर एक ही समय पर क्रेडेंशियल को रीफ़्रेश करने की कोशिश न करें, इसकी वजह से बहुत ज़्यादा रीफ़्रेश अनुरोध आते हैं, आपको रीफ़्रेश को किसी एक प्रोसेस के लिए असाइन करना चाहिए.
उदाहरण के लिए, किसी अलग नौकरी या सेवा की ज़िम्मेदारी यह हो सकती है कि वह समय-समय पर क्रेडेंशियल को रीफ़्रेश करे और उसे सर्वर के पूल से शेयर किए गए डेटा स्टोर पर भेजे. इसके बाद, एपीआई अनुरोध करते समय हर सर्वर, डेटा स्टोर से क्रेडेंशियल को वापस ला सकता है.
नौकरी की जानकारी रीफ़्रेश करें
रीफ़्रेश करने के लिए, मौजूदा क्रेडेंशियल की समयसीमा खत्म होने का इंतज़ार नहीं करना चाहिए. ऐसा करने से, मान्य क्रेडेंशियल न होने की वजह से ऐप्लिकेशन बंद हो सकता है. हालांकि, अगर एपीआई अनुरोध पर कार्रवाई होने के दौरान, क्रेडेंशियल का ऐक्सेस टोकन खत्म हो जाता है, तब भी अनुरोध पूरा होगा और नतीजे दिखाए जाएंगे.
हमारा सुझाव है कि आप उस समय को ट्रैक करें जब आपका ऐक्सेस टोकन पिछली बार रीफ़्रेश किया गया था. अगर समयसीमा खत्म होने में 5 मिनट से कम समय है, तो उसे रीफ़्रेश करें.
अगर आपको नहीं पता कि ऐक्सेस टोकन को आखिरी बार कब रीफ़्रेश किया गया था, तो यह मानकर रीफ़्रेश करें कि उसकी समयसीमा खत्म हो चुकी है. अगर ऐक्सेस टोकन लैप्स होने के करीब नहीं है, तो सर्वर उसी ऐक्सेस टोकन को दिखाता है. साथ ही, टोकन की समयसीमा खत्म होने तक बाकी मिलीसेकंड भी दिखाता है.
डेटा स्टोर
किसी मौजूदा डेटा स्टोर का इस्तेमाल किया जा सकता है या सर्वर के बीच क्रेडेंशियल शेयर करने के लिए, किसी एक डेटा स्टोर को डिप्लॉय किया जा सकता है. समाधान में कैश मेमोरी सर्वर शामिल होते हैं, जैसे कि Memcached या Infinispan या NoSQL डेटा स्टोर, जैसे कि MongoDB.
डेटा स्टोर को तेज़ पढ़ने की कार्रवाइयों के लिए ऑप्टिमाइज़ किया जाना चाहिए, क्योंकि लिखने के मुकाबले पढ़ने के लिए ज़्यादा अनुरोध होंगे. क्रेडेंशियल सुरक्षित तरीके से सेव होने चाहिए.
क्रेडेंशियल को सेव करते समय, आपके दिए गए फ़ॉर्मूला के आधार पर तैयार किए गए expiry_time
(अब + expires_in) और refresh_token को access_token के साथ सेव करना चाहिए. expiry_time का हिसाब, access_token को रीफ़्रेश करने के अनुरोध के समय और expires_in के समय को कैलकुलेट किया जाता है.
सर्वर पूल
कोई अनुरोध करने से पहले, पूल में मौजूद हर सर्वर या प्रोसेस, डेटा स्टोर से नया क्रेडेंशियल डाउनलोड करती है. जब तक रीफ़्रेश ठीक से चल रहा है, क्रेडेंशियल मान्य रहेगा. हालांकि, अगर रीफ़्रेश जॉब या डेटा स्टोर काम नहीं करता, तो आपके पास फ़ॉलबैक मैकेनिज़्म होना चाहिए.
अगर किसी सर्वर या प्रोसेस को डेटा स्टोर से क्रेडेंशियल नहीं मिल सकता या क्रेडेंशियल की समयसीमा खत्म हो गई है, तो सर्वर को अपने क्रेडेंशियल रीफ़्रेश करने चाहिए, ताकि समस्या हल होने तक ऐप्लिकेशन एपीआई के साथ काम करता रहे.
एक से ज़्यादा खातों के लिए क्रेडेंशियल मैनेजमेंट
Google Ads मैनेजर खाते के लिए जनरेट किए गए क्रेडेंशियल का इस्तेमाल, उसके सभी चाइल्ड खातों को ऐक्सेस करने के लिए किया जा सकता है. इसलिए, एक मैनेजर खाते के क्रम वाले उपयोगकर्ताओं के लिए, आम तौर पर टॉप-लेवल मैनेजर खाते के लिए एक क्रेडेंशियल जनरेट करना काफ़ी होता है, ताकि उसका इस्तेमाल सभी Google Ads खातों के लिए किया जा सके.
अगर आपके ऐप्लिकेशन को ऐसे Google Ads खातों को ऐक्सेस करना है जो किसी भी मैनेजर खाते के क्रम में एक-दूसरे से जुड़े नहीं हैं, तो आपको अलग-अलग खातों के लिए अलग-अलग क्रेडेंशियल जनरेट करने और उन्हें बनाए रखने होंगे. जैसे, हर उस Google Ads क्लाइंट खाते के लिए जिसे आपने ऐक्सेस किया है या आपके ऐक्सेस किए गए स्वतंत्र हैरारकी के हर टॉप-लेवल मैनेजर खाते के लिए.
मामूली बदलाव करके, मल्टीथ्रेड या मल्टीप्रोसेस / डिस्ट्रिब्यूटेड ऐप्लिकेशन के लिए भी वही रणनीतियां अपनाई जा सकती हैं. शेयर किए गए डेटा स्टोर का इस्तेमाल करते समय, क्रेडेंशियल को खाता आइडेंटिफ़ायर customerId से इंडेक्स किया जाना चाहिए. इससे यह पक्का किया जा सकता है कि क्रेडेंशियल सही खाते से जुड़े हैं.
इसके अलावा, रीफ़्रेश जॉब में सभी क्रेडेंशियल रीफ़्रेश होने चाहिए. अगर कोई नया खाता लिंक है, तो रीफ़्रेश करने का काम ट्रिगर करना पड़ सकता है.
आखिर में, मल्टीथ्रेड ऐप्लिकेशन में, आपको सिर्फ़ उन थ्रेड में क्रेडेंशियल ऑब्जेक्ट शेयर करना चाहिए जो उस खाते पर काम कर रहे हैं जिससे क्रेडेंशियल ऑब्जेक्ट जुड़ा है.