सबसे अच्छे तरीके

इस पेज में ऐसे कई सबसे सही तरीकों के बारे में बताया गया है जिन पर Google Ad Manager API के लिए ऐप्लिकेशन बनाते समय ध्यान देना चाहिए.

प्रोग्राम चलाने के दौरान, सेवा क्लाइंट/स्टब का फिर से इस्तेमाल करना

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

ऑब्जेक्ट फ़ेच करते समय पेजिंग का इस्तेमाल करें

सभी सेवाएं get*ByStatement() तरीके के साथ काम करती हैं. इससे पीक्यूएल सिंटैक्स का इस्तेमाल करके, नतीजों को फ़िल्टर किया जा सकता है. LIMIT और OFFSET क्लॉज़ का इस्तेमाल, नतीजों के बड़े सेट को पेजों में बांटने के लिए किया जा सकता है. इससे समय खत्म होने और रिस्पॉन्स पेज के साइज़ को सही रखने में मदद मिलती है. आपके ऑब्जेक्ट की जटिलता पर निर्भर करते हुए, सुझाया गया पेज 200-500 है.

बैच अपडेट के अनुरोध

एक ही तरह के कई ऑब्जेक्ट में बदलाव करने पर, बेहतर परफ़ॉर्मेंस मिल सकती है. इसके लिए, सभी ऑब्जेक्ट को एक ही update*() अनुरोध के साथ भेजा जा सकता है. हर अनुरोध के लिए, क्लाइंट और सर्वर पर एक मार्जिनल ओवरहेड होता है. साथ ही, बैच बनाने की सुविधा, अनुरोधों की संख्या को कम करने का एक असरदार तरीका हो सकती है. उदाहरण के लिए, हर कॉल में एक ऑर्डर के बजाय ऑर्डर के बैच को अपडेट करने के लिए, updateOrders का इस्तेमाल करें.

PQL में बाइंड पैरामीटर का इस्तेमाल करें

बाइंड पैरामीटर, वैरिएबल को PQL क्वेरी स्टेटमेंट में रखने का एक तरीका है. पीक्यूएल, कोलन से शुरू होने वाले स्पेस के बिना नाम वाले बाइंड वैरिएबल का मतलब है, जैसे, :name. पीक्यूएल सिंटैक्स पेज पर, कोड का एक उदाहरण दिया गया है.

हम बाइंड वैरिएबल का इस्तेमाल करने का सुझाव देते हैं, क्योंकि वे स्ट्रिंग और वैरिएबल को एक क्वेरी स्टेटमेंट में जोड़ने की ज़रूरत को हटा देते हैं. इससे कोड को बेहतर तरीके से पढ़ा जा सकता है. इनसे पीक्यूएल स्टेटमेंट को फिर से इस्तेमाल करना आसान हो जाता है, क्योंकि बाइंड पैरामीटर वैल्यू को बदलकर नई क्वेरी बनाई जा सकती हैं.

लोगों को खास अधिकार दें

उपयोगकर्ता की भूमिकाएं बनाने/अपडेट करने के लिए, UserService का इस्तेमाल करते समय, उपयोगकर्ताओं को वे अधिकार न दें जिनकी उन्हें ज़रूरत नहीं है. एपीआई की कई सुविधाओं को, एडमिन की भूमिका असाइन करने के बजाय, कई भूमिकाओं से ऐक्सेस किया जा सकता है. किसी उपयोगकर्ता को कौनसी भूमिकाएं असाइन करनी हैं, यह तय करने के लिए कृपया अनुमतियों का दस्तावेज़ देखें. साथ ही, तीसरे पक्ष के ऐप्लिकेशन डेवलपर के तौर पर, यह पक्का करें कि किसी नेटवर्क को आपके लिए उपयोगकर्ता बनाने के लिए कहते समय, आपके ऐप्लिकेशन को किस लेवल का ऐक्सेस चाहिए. एडमिन की तुलना में कम खास अधिकारों वाली भूमिका पर्याप्त हो सकती है.

स्टोरेज को कोटे के अंदर रखें

Ad Manager API, मज़बूती के लिए कई कोटा सीमाएं लागू करता है. अपने ऐप्लिकेशन को इन सीमाओं के तहत रखना ज़रूरी है. साथ ही, यह भी पता होना चाहिए कि एपीआई से मिलने वाली, कोटा की गड़बड़ियों से जुड़ी समस्याओं का जवाब कैसे दिया जाए.

एपीआई कोटा

एपीआई अनुरोधों पर लागू किया गया पहला कोटा, नेटवर्क-लेवल का कोटा होता है. Ad Manager 360 खातों के लिए, यह सीमा एक सेकंड में आठ और Ad Manager खातों के लिए दो अनुरोध प्रति सेकंड की हो सकती है. इस सीमा से आगे जाने पर, QuotaError.EXCEEDED_QUOTA गड़बड़ी दिखती है. आपके नेटवर्क पर किए गए सभी एपीआई अनुरोध इस कोटा पर लागू होते हैं. इसमें तीसरे पक्ष के ऐसे ऐप्लिकेशन भी शामिल हैं जिन्हें आपने या आपकी कंपनी के किसी व्यक्ति ने आपके नेटवर्क को एपीआई का ऐक्सेस दिया है.

सिस्टम के हिसाब से कोटा

Ad Manager में मौजूद कुछ रिसॉर्स-इंटेसिव सिस्टम की सुरक्षा के लिए, सिर्फ़ एपीआई कोटा ही काफ़ी नहीं है. रिपोर्टिंग और अनुमान लगाने वाले सिस्टम अपने-अपने कोटा तय करते हैं, जिनकी वजह से एपीआई से जुड़ी गड़बड़ियां हो सकती हैं: QuotaError.REPORT_JOB_LIMIT और ForecastError.EXCEEDED_QUOTA.

कोटा से जुड़ी गड़बड़ियां ठीक करना

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