अनुमति देना
Google Photos Library API को ऐक्सेस करने के लिए किए गए सभी अनुरोधों की अनुमति, किसी ऐसे उपयोगकर्ता को दी जानी चाहिए जिसकी पुष्टि हो चुकी हो.
OAuth 2.0 के लिए अनुमति पाने की प्रोसेस अलग-अलग हो सकती है किस तरह का ऐप्लिकेशन लिखा जा रहा है. नीचे दी गई सामान्य प्रोसेस ऐप्लिकेशन के सभी टाइप पर लागू होता है:
- अनुमति देने की प्रक्रिया शुरू करने के लिए, यह तरीका अपनाएं:
- इसका उपयोग करके अपना ऐप्लिकेशन पंजीकृत करें Google API कंसोल.
- Library API को चालू करें और OAuth की जानकारी वापस पाएं. जैसे, क्लाइंट आईडी और क्लाइंट सीक्रेट. ज़्यादा जानकारी के लिए, यह देखें शुरू करें.
- उपयोगकर्ता के डेटा को ऐक्सेस करने के लिए, यह ऐप्लिकेशन Google से अनुरोध करता है कि वह के दायरे में आते हैं.
- Google उपयोगकर्ता को एक सहमति स्क्रीन दिखाता है, जिसमें उनसे अनुमति देने के लिए कहा जाता है कुछ डेटा का अनुरोध करने के लिए डिज़ाइन किया जाता है.
- अगर उपयोगकर्ता अनुमति देता है, तो Google ऐप्लिकेशन को ऐक्सेस टोकन के साथ उपलब्ध कराता है जिसकी समयसीमा कुछ समय बाद खत्म हो जाती है.
- ऐप्लिकेशन, ऐक्सेस टोकन अटैच करके उपयोगकर्ता के डेटा के लिए अनुरोध करता है उस सवाल का जवाब दें.
- अगर Google को पता चलता है कि अनुरोध और टोकन मान्य हैं, तो यह का अनुरोध किया गया है.
यह तय करने के लिए कि आपके ऐप्लिकेशन के लिए कौनसे दायरे सही हैं, अनुमति देना देखें दायरे.
कुछ ऐप्लिकेशन टाइप की प्रक्रिया में अतिरिक्त चरण शामिल होते हैं, जैसे कि नए ऐक्सेस टोकन पाने के लिए, टोकन रीफ़्रेश करें. इसके बारे में ज़्यादा जानकारी पाने के लिए के लिए उपलब्ध है, तो Google को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना देखें APIs.
कैश मेमोरी में सेव करना
डेटा को अप-टू-डेट रखें.
अगर आपको मीडिया (जैसे कि थंबनेल, फ़ोटो या वीडियो) को कुछ समय के लिए सेव करना है, तो की वजह से, इसे हमारे इस्तेमाल के हिसाब से 60 मिनट से ज़्यादा समय के लिए कैश मेमोरी में सेव न करें दिशा-निर्देशों का पालन करें.
आपको baseUrls को भी सेव नहीं करना चाहिए, जिसकी समयसीमा 60 दिनों के बाद खत्म हो जाती है
मिनट.
मीडिया आइटम आईडी और एल्बम आईडी, जो उपयोगकर्ता की लाइब्रेरी में मौजूद कॉन्टेंट की खास तौर पर पहचान करते हैं उन्हें कैश मेमोरी में सेव करने की पाबंदी नहीं है. इन आईडी को हमेशा के लिए सेव किया जा सकता है (आपके ऐप्लिकेशन की निजता नीति के अधीन). मीडिया आइटम आईडी और एल्बम आईडी का इस्तेमाल करें का इस्तेमाल करें, ताकि ऐक्सेस किए जा सकने वाले यूआरएल और डेटा को फिर से वापस पाया जा सके. इसके लिए ज़्यादा जानकारी के लिए, मीडिया से जुड़ी समस्या को हल करने के लिए, आइटम या लिस्टिंग एल्बम होंगे.
अगर आपको रीफ़्रेश करने के लिए कई मीडिया आइटम हैं, तो बेहतर होगा कि आप अपनी फ़ाइल में वे खोज पैरामीटर जिन्होंने मीडिया आइटम लौटाए और फिर से लोड करने के लिए क्वेरी को दोबारा सबमिट किया डेटा शामिल है.
एसएसएल ऐक्सेस
एचटीटीपीएस का इस्तेमाल उन सभी Library API वेब सेवा अनुरोधों के लिए ज़रूरी है जो निम्न URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
एचटीटीपी पर किए गए अनुरोध अस्वीकार कर दिए जाते हैं.
गड़बड़ी ठीक करना
एपीआई से मिली गड़बड़ियों को ठीक करने के तरीके के बारे में जानकारी के लिए, Cloud देखें एपीआई हैंडलिंग गड़बड़ियां शामिल हैं.
पूरे न हो पाने वाले अनुरोधों की फिर से कोशिश की जा रही है
एक्स्पोनेंशियल बैकऑफ़ वाली 5xx गड़बड़ियों के लिए, क्लाइंट को फिर से कोशिश करनी चाहिए, जैसा कि यहां बताया गया है
एक्सपोनेन्शियल बैकऑफ़. कम से कम 1 s की देरी होनी चाहिए
जब तक अलग से दस्तावेज़ न दिए जाएं.
429 गड़बड़ियों के लिए, क्लाइंट कम से कम 30s की देरी करके फिर से कोशिश कर सकता है. अन्य सभी के लिए
गड़बड़ियां हो सकती हैं, तो हो सकता है कि फिर से कोशिश करने की सुविधा लागू न हो. पक्का करें कि आपका अनुरोध एकजुट है. साथ ही, यह देखें
देखें.
एक्स्पोनेंशियल बैकऑफ़
बहुत कम मामलों में, आपका अनुरोध पूरा करने में कोई गड़बड़ी हो सकती है.आपको
4XX या 5XX एचटीटीपी रिस्पॉन्स कोड या टीसीपी कनेक्शन कहीं काम नहीं कर सकता
आपके क्लाइंट और Google के सर्वर के बीच स्विच कर सकता है. अक्सर, पुनः प्रयास करना फ़ायदेमंद होता है
अनुरोध. पहला अनुरोध पूरा न होने पर, फ़ॉलो अप अनुरोध पूरा हो सकता है. हालांकि,
यह ज़रूरी है कि आप Google के सर्वर से बार-बार अनुरोध करके, लूप न करें. यह
लूप में चलने वाले व्यवहार से, आपके क्लाइंट और Google के बीच नेटवर्क पर ओवरलोड हो सकता है
कई पक्षों के लिए समस्या पैदा करता हो.
एक बेहतर तरीका यह है कि दो कोशिशों के बीच में देरी होने पर, फिर से कोशिश करें. आम तौर पर, हर बार कोशिश करने पर, देरी को मल्टीप्लिकेटिव फ़ैक्टर से बढ़ाया जाता है. इसे घातांकीय कहा जाता है बैकऑफ़.
आपको इस बात का भी ध्यान रखना चाहिए कि ऐप्लिकेशन में कोड को फिर से लोड करने की कोशिश न की जाए यह एक कॉल चेन है, जो एक के बाद एक कई अनुरोधों पर ले जाती है.
Google API का आसान इस्तेमाल
खराब तरीके से डिज़ाइन किए गए एपीआई क्लाइंट, दोनों पर ज़रूरत से ज़्यादा लोड कर सकते हैं के सर्वर पर रखा जाता है. इस सेक्शन में, एपीआई के क्लाइंट. इन सबसे सही तरीकों को अपनाकर, ऐप्लिकेशन को एपीआई के अनजाने में गलत इस्तेमाल के लिए ब्लॉक किया जा रहा है.
सिंक किए गए अनुरोध
Google के API के लिए बड़ी संख्या में सिंक किए गए अनुरोध Google के इंफ़्रास्ट्रक्चर पर डिस्ट्रिब्यूटेड डिनायल ऑफ़ सर्विस (डीडीओएस) हमला और इन पर काम न करे. इससे बचने के लिए, पक्का करें कि एपीआई अनुरोध क्लाइंट के बीच सिंक नहीं किया गया है.
उदाहरण के लिए, ऐसे ऐप्लिकेशन पर विचार करें जो मौजूदा समय को दिखाता हो ज़ोन. यह ऐप्लिकेशन शायद क्लाइंट के ऑपरेटिंग सिस्टम में अलार्म सेट करेगा स्क्रीन को मिनट की शुरुआत में जगाना, ताकि डिसप्ले होने वाला समय दिया जा सके अपडेट किया गया. ऐप्लिकेशन को प्रोसेस के हिस्से के तौर पर कोई एपीआई कॉल नहीं करना चाहिए उस अलार्म से जुड़े थे.
किसी तय अलार्म के जवाब में एपीआई कॉल करना खराब होता है, क्योंकि इससे एपीआई कॉल को मिनट की शुरुआत में सिंक किया जा रहा है. भले ही, ये दोनों अलग-अलग समय पर हों अलग-अलग डिवाइसों पर समान रूप से खर्च करना. खराब तरीके से डिज़ाइन किया गया ऐसा करने से ट्रैफ़िक में सामान्य स्तर पर साठ गुना बढ़ोतरी हुई हर मिनट की शुरुआत में दिखेगा.
इसके बजाय, एक दूसरा अलार्म यह भी हो सकता है कि वह बिना किसी तय क्रम के चुना गया समय. जब यह दूसरा अलार्म सक्रिय होता है, तो यह ऐप्लिकेशन किसी भी इसकी ज़रूरत वाले एपीआई और नतीजों को सेव करता है. इसके डिसप्ले को अपडेट करने के लिए, मिनट, एप्लिकेशन एपीआई को फिर से खोलें. इस तरीके से, एपीआई कॉल समय के साथ समान रूप से बांटे जाते हैं. इसके अलावा, डिसप्ले को अपडेट करते समय, एपीआई कॉल से रेंडरिंग में देरी नहीं होती.
मिनट की शुरुआत के अलावा, अन्य सामान्य सिंक्रोनाइज़ेशन समय ध्यान रखें कि वे एक घंटे के शुरू में और रोज़ाना आधी रात को.