सर्वोत्तम प्रक्रियाएं

अनुमति देना

Google Photos के एपीआई को भेजे गए सभी अनुरोधों के लिए अनुमति किसी ऐसे उपयोगकर्ता को देनी चाहिए जिसके पास ऐसा करने का अधिकार हो.

OAuth 2.0 के लिए अनुमति देने की प्रक्रिया की जानकारी अलग-अलग हो सकती है. यह इस बात पर निर्भर करता है कि ऐप्लिकेशन किस तरह का है. सभी तरह के ऐप्लिकेशन के लिए, नीचे दी गई सामान्य प्रोसेस लागू होती है:

  1. अनुमति की प्रक्रिया के लिए तैयारी करने के लिए, यह तरीका अपनाएं:
    • Google API कंसोल का इस्तेमाल करके, अपना ऐप्लिकेशन रजिस्टर करें.
    • Photos API को चालू करें और OAuth की जानकारी पाएं. जैसे, क्लाइंट आईडी और क्लाइंट सीक्रेट. ज़्यादा जानकारी के लिए, शुरू करना देखें.
  2. उपयोगकर्ता का डेटा ऐक्सेस करने के लिए, ऐप्लिकेशन Google से ऐक्सेस के किसी खास दायरे का अनुरोध करता है.
  3. Google, उपयोगकर्ता को सहमति वाली स्क्रीन दिखाता है. इसमें उनसे ऐप्लिकेशन को उनके कुछ डेटा को ऐक्सेस करने की अनुमति मांगी जाती है.
  4. अगर उपयोगकर्ता अनुमति देता है, तो Google ऐप्लिकेशन को एक ऐक्सेस टोकन देता है, जो कुछ समय बाद खत्म हो जाता है.
  5. ऐप्लिकेशन, ऐक्सेस टोकन को अनुरोध से जोड़कर, उपयोगकर्ता के डेटा को ऐक्सेस करने का अनुरोध करता है.
  6. अगर Google को पता चलता है कि अनुरोध और टोकन मान्य है, तो वह आपके ऐप्लिकेशन को अनुरोध किया गया डेटा दिखाता है.

यह तय करने के लिए कि आपके ऐप्लिकेशन के लिए कौनसे स्कोप सही हैं, अनुमति के स्कोप देखें.

कुछ तरह के ऐप्लिकेशन के लिए, प्रोसेस में कुछ और चरण शामिल होते हैं. जैसे, नए ऐक्सेस टोकन पाने के लिए रिफ़्रेश टोकन का इस्तेमाल करना. अलग-अलग तरह के ऐप्लिकेशन के लिए डेटा ऐक्सेस करने के तरीकों के बारे में ज़्यादा जानकारी पाने के लिए, Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

कैश मेमोरी में सेव करना

डेटा को अप-टू-डेट रखें.

अगर आपको परफ़ॉर्मेंस से जुड़ी वजहों से, कुछ समय के लिए मीडिया (जैसे, थंबनेल, फ़ोटो या वीडियो) को सेव करना है, तो उसे 60 मिनट से ज़्यादा समय तक कैश मेमोरी में सेव न रखें. ऐसा, इस्तेमाल से जुड़े हमारे दिशा-निर्देशों के मुताबिक करना ज़रूरी है.

आपको baseUrls को भी स्टोर नहीं करना चाहिए, जो करीब 60 मिनट के बाद खत्म हो जाता है.

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

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

एसएसएल ऐक्सेस

इस यूआरएल का इस्तेमाल करके, Photos API की वेब सेवा के सभी अनुरोधों के लिए एचटीटीपीएस का इस्तेमाल करना ज़रूरी है:

https://photoslibrary.googleapis.com/v1/service/output?parameters

एचटीटीपी के ज़रिए किए गए अनुरोध अस्वीकार कर दिए जाते हैं.

गड़बड़ी ठीक करना

एपीआई से मिली गड़बड़ियों को मैनेज करने के तरीके के बारे में जानने के लिए, Cloud एपीआई गड़बड़ियों को मैनेज करना लेख पढ़ें.

पूरे न हो पाने वाले अनुरोधों को फिर से भेजना

क्लाइंट को 5xx गड़बड़ियों पर, एक्सपोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करनी चाहिए, जैसा कि एक्सपोनेंशियल बैकऑफ़ में बताया गया है. अगर कोई अन्य दस्तावेज़ नहीं दिया गया है, तो कम से कम 1 s देर होनी चाहिए.

429 गड़बड़ियों के लिए, क्लाइंट कम से कम 30s देरी के साथ फिर से कोशिश कर सकता है. अन्य सभी गड़बड़ियों के लिए, फिर से कोशिश करने की सुविधा काम नहीं कर सकती. पक्का करें कि आपका अनुरोध, एक बार में कई बार लागू न होता हो. साथ ही, गड़बड़ी के मैसेज में दिए गए निर्देश देखें.

एक्सपोनेंशियल बैकऑफ़

कुछ मामलों में, आपके अनुरोध को पूरा करने में कोई गड़बड़ी हो सकती है. आपको 4XX या 5XX एचटीटीपी रिस्पॉन्स कोड मिल सकता है. इसके अलावा, आपके क्लाइंट और Google के सर्वर के बीच कहीं भी टीसीपी कनेक्शन काम नहीं कर सकता. आम तौर पर, अनुरोध फिर से करने से फ़ायदा होता है. अगर मूल अनुरोध पूरा नहीं हो पाता है, तो फ़ॉलो अप अनुरोध पूरा हो सकता है. हालांकि, Google के सर्वर से बार-बार अनुरोध करने के लिए, इसे लूप में न रखें. इस तरह के व्यवहार से, आपके क्लाइंट और Google के बीच के नेटवर्क पर लोड बढ़ सकता है. साथ ही, कई पक्षों को समस्याएं हो सकती हैं.

बेहतर तरीका यह है कि हर बार थोड़ी देर बाद कोशिश की जाए. आम तौर पर, हर कोशिश के साथ, इंतज़ार का समय कई गुना बढ़ जाता है. इसे एक्सपोनेंशियल बैकऑफ़ कहा जाता है.

आपको यह भी ध्यान रखना चाहिए कि ऐप्लिकेशन कॉल चेन में, फिर से कोशिश करने का कोड ऊपर न हो. इससे, एक के बाद एक बार-बार अनुरोध किए जाते हैं.

Google API का सही तरीके से इस्तेमाल करना

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

सिंक किए गए अनुरोध

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

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

तय समय पर बजने वाले अलार्म के जवाब में एपीआई कॉल करना अच्छा नहीं है. ऐसा करने पर, एपीआई कॉल को समय के हिसाब से बराबर बांटने के बजाय, मिनट की शुरुआत में सिंक किया जाता है. यह सिंक अलग-अलग डिवाइसों के बीच भी किया जाता है. खराब तरीके से डिज़ाइन किए गए ऐप्लिकेशन में ऐसा करने पर, हर मिनट की शुरुआत में सामान्य लेवल के मुकाबले ट्रैफ़िक में 60 गुना बढ़ोतरी होती है.

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

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