Play की गेम सेवाओं को पब्लिश करने वाले एपीआई की मदद से, किसी गेम के लिए इमेज अपलोड की जा सकती है.
अपलोड करने के विकल्प
Play की गेम सेवाओं को पब्लिश करने वाले एपीआई की मदद से, कुछ खास बाइनरी डेटा या मीडिया को अपलोड किया जा सकता है. मीडिया अपलोड की सुविधा देने वाले किसी भी तरीके के लिए, पहचान की जानकारी देने वाले पेज पर, आपके अपलोड किए गए डेटा की खास जानकारी दी गई है:
- अपलोड की जाने वाली फ़ाइल का साइज़: ज़्यादा से ज़्यादा कितना डेटा सेव किया जा सकता है.
- स्वीकार किए जाने वाले MIME टाइप: ऐसे बाइनरी डेटा के टाइप जिन्हें इस तरीके से सेव किया जा सकता है.
नीचे दिए गए किसी भी तरीके का इस्तेमाल करके, वीडियो अपलोड करने का अनुरोध किया जा सकता है. uploadType
अनुरोध पैरामीटर के साथ इस्तेमाल किया जाने वाला तरीका बताएं.
- अपलोड करने में आसान:
uploadType=media
. छोटी फ़ाइलों को तुरंत ट्रांसफ़र करने के लिए, जैसे कि 5 एमबी या इससे कम. - मल्टीपार्ट अपलोड:
uploadType=multipart
. छोटी फ़ाइलों और मेटाडेटा को तुरंत ट्रांसफ़र करने के लिए, फ़ाइल को मेटाडेटा के साथ ट्रांसफ़र करें. इससे, वह मेटाडेटा एक ही अनुरोध में ट्रांसफ़र हो जाता है. - फिर से अपलोड किया जा सकता है:
uploadType=resumable
. फ़ाइलों का भरोसेमंद ट्रांसफ़र करने के लिए, खास तौर पर बड़ी फ़ाइलों के लिए ऐसा करना ज़रूरी है. इस तरीके से, आपको सेशन शुरू करने के अनुरोध का इस्तेमाल किया जाता है, जिसमें वैकल्पिक रूप से मेटाडेटा शामिल हो सकता है. यह ज़्यादातर ऐप्लिकेशन के लिए इस्तेमाल की जाने वाली अच्छी रणनीति है, क्योंकि यह हर अपलोड के लिए एक अतिरिक्त एचटीटीपी अनुरोध की लागत पर छोटी फ़ाइलों के लिए भी काम करती है.
मीडिया को अपलोड करते समय, एक खास यूआरआई का इस्तेमाल किया जाता है. असल में, मीडिया अपलोड का समर्थन करने वाले तरीकों में दो यूआरआई एंडपॉइंट होते हैं:
मीडिया के लिए, /upload यूआरआई. अपलोड एंडपॉइंट का फ़ॉर्मैट एक मानक संसाधन यूआरआई है, जिसमें “/upload” प्रीफ़िक्स है. मीडिया डेटा को ट्रांसफ़र करते समय, इस यूआरआई का इस्तेमाल करें.
उदाहरण:
POST /upload/games/v1configuration/images/resourceId/imageType/imageType
मेटाडेटा के लिए स्टैंडर्ड रिसॉर्स यूआरआई. अगर रिसॉर्स में कोई डेटा फ़ील्ड है, तो उन फ़ील्ड का इस्तेमाल, अपलोड की गई फ़ाइल के बारे में जानकारी देने वाले मेटाडेटा को स्टोर करने के लिए किया जाता है. इस यूआरआई का इस्तेमाल मेटाडेटा वैल्यू बनाते या अपडेट करते समय किया जा सकता है.
उदाहरण:
POST /games/v1configuration/images/resourceId/imageType/imageType
अपलोड करने में आसान
फ़ाइल अपलोड करने का सबसे आसान तरीका है, एक आसान अपलोड अनुरोध करना. यह विकल्प तब एक अच्छा विकल्प होता है, जब:
- कनेक्शन खराब हो जाने पर फ़ाइल पूरी तरह से फिर से अपलोड होने के लिए काफ़ी छोटी हो जाती है.
- भेजने के लिए कोई मेटाडेटा नहीं है. अगर आप इस संसाधन के लिए मेटाडेटा भेजने के लिए अलग अनुरोध करते हैं या ऐसा कोई मेटाडेटा काम नहीं करता या उपलब्ध नहीं है, तो यह तरीका सही हो सकता है.
सामान्य अपलोड का इस्तेमाल करने के लिए, तरीके के
/upload यूआरआई में POST
या PUT
का अनुरोध करें और क्वेरी पैरामीटर
uploadType=media
जोड़ें. उदाहरण के लिए:
POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media
अपलोड करने के आसान अनुरोध के दौरान, इस्तेमाल किए जाने वाले एचटीटीपी हेडर में ये शामिल हैं:
Content-Type
एपीआई के रेफ़रंस रेफ़रंस में दिए गए, तरीकों में से किसी एक तरह के अपलोड मीडिया डेटा सेट करें.Content-Length
. उन बाइट की संख्या सेट करें जो आप अपलोड कर रहे हैं. अगर आप शेयर किए गए ट्रांसफ़र को कोड में बदलने का तरीका इस्तेमाल कर रहे हैं, तो यह ज़रूरी नहीं है.
उदाहरण: आसान अपलोड
नीचे दिए गए उदाहरण में, 'Play की गेम सेवाओं को पब्लिश करने वाले एपीआई' के लिए, अपलोड करने के सामान्य अनुरोध का इस्तेमाल करने के बारे में बताया गया है.
POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media HTTP/1.1 Host: www.googleapis.com Content-Type: image/png Content-Length: number_of_bytes_in_file Authorization: Bearer your_auth_token PNG data
अनुरोध पूरा होने पर, सर्वर किसी भी मेटाडेटा के साथ एचटीटीपी स्टेटस 200 OK
कोड दिखाता है:
HTTP/1.1 200 Content-Type: application/json {
"kind": "gamesConfiguration#imageConfiguration",
"url": string,
"resourceId": string,
"imageType": string
}
कई हिस्सों में अपलोड करें
अगर आपके पास ऐसा मेटाडेटा है जिसे आप अपलोड करने के लिए डेटा के साथ भेजना चाहते हैं, तो आप सिर्फ़ एक multipart/related
अनुरोध कर सकते हैं. अगर आपका डेटा इतना छोटा है कि कनेक्शन नहीं हो पाता है, तो यह एक अच्छा विकल्प है.
मल्टीपार्ट अपलोड का इस्तेमाल करने के लिए, तरीके के /upload यूआरआई में POST
या PUT
का अनुरोध करें और क्वेरी पैरामीटर
uploadType=multipart
जोड़ें, जैसे:
POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart
एक से ज़्यादा हिस्सों वाले अपलोड अनुरोध करते समय, इस्तेमाल करने के लिए टॉप-लेवल एचटीटीपी हेडर शामिल हैं:
Content-Type
को कई हिस्सों/एक साथ सेट करें. साथ ही, अनुरोध के हिस्सों की पहचान करने के लिए, जिस सीमा स्ट्रिंग का इस्तेमाल कर रहे हैं उसे शामिल करें.Content-Length
, अनुरोध के मुख्य हिस्से में बाइट की कुल संख्या पर सेट करें. अनुरोध का मीडिया हिस्सा इस तरीके से तय की गई ज़्यादा से ज़्यादा फ़ाइल आकार से कम होना चाहिए.
अनुरोध के मुख्य हिस्से का फ़ॉर्मैट, multipart/related
कॉन्टेंट टाइप [RFC2387] के तौर पर दिया जाता है. इसमें सिर्फ़ दो हिस्से होते हैं. हिस्सों की पहचान, सीमा स्ट्रिंग से की जाती है. आखिरी सीमा स्ट्रिंग के बाद, दो हाइफ़न डाले जाते हैं.
एक से ज़्यादा हिस्सों वाले अनुरोध के हर हिस्से के लिए एक अतिरिक्त Content-Type
हेडर की ज़रूरत होती है:
- मेटाडेटा पार्ट: पहले आना चाहिए और
Content-Type
को स्वीकार किए गए मेटाडेटा फ़ॉर्मैट में से किसी एक से मेल खाना चाहिए. - मीडिया वाला हिस्सा: दूसरा होना ज़रूरी है. साथ ही,
Content-Type
, मीडिया के MIME टाइप में से किसी एक से मेल खाना चाहिए.
हर तरीके का मीडिया MIME टाइप और अपलोड की गई फ़ाइलों के साइज़ की सीमा की सूची के लिए, एपीआई रेफ़रंस देखें.
ध्यान दें: सिर्फ़ मेटाडेटा से जुड़ा डेटा बनाने या उसे अपडेट करने के लिए, उससे जुड़े डेटा को अपलोड किए बिना, स्टैंडर्ड रिसॉर्स एंडपॉइंट पर POST
या PUT
का अनुरोध भेजें:
https://www.googleapis.com/games/v1configuration/images/resourceId/imageType/imageType
उदाहरण: कई हिस्सों में अपलोड करें
नीचे दिए गए उदाहरण में, Play की गेम सेवाओं को पब्लिश करने वाले एपीआई के लिए, कई हिस्सों में अपलोड करने का अनुरोध दिखाया गया है.
POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart HTTP/1.1 Host: www.googleapis.com Authorization: Bearer your_auth_token Content-Type: multipart/related; boundary=foo_bar_baz Content-Length: number_of_bytes_in_entire_request_body --foo_bar_baz Content-Type: application/json; charset=UTF-8 {
"kind": "gamesConfiguration#imageConfiguration",
"url": string,
"resourceId": string,
"imageType": string
} --foo_bar_baz Content-Type: image/png PNG data --foo_bar_baz--
अनुरोध पूरा होने पर, सर्वर किसी भी मेटाडेटा के साथ एचटीटीपी 200 OK
स्टेटस कोड दिखाता है:
HTTP/1.1 200 Content-Type: application/json {
"kind": "gamesConfiguration#imageConfiguration",
"url": string,
"resourceId": string,
"imageType": string
}
फिर से अपलोड किया जा सकता है
डेटा फ़ाइलों को ज़्यादा भरोसेमंद तरीके से अपलोड करने के लिए, फिर से शुरू करने वाले अपलोड प्रोटोकॉल का इस्तेमाल किया जा सकता है. संचार में हुई रुकावट की वजह से डेटा के फ़्लो में रुकावट आने पर, इस प्रोटोकॉल के ज़रिए अपलोड की प्रक्रिया को फिर से शुरू किया जा सकता है. यह खास तौर पर तब फ़ायदेमंद होता है, जब आप बड़ी फ़ाइलें ट्रांसफ़र कर रहे हों और नेटवर्क में रुकावट आने या डेटा ट्रांसफ़र होने की कोई और वजह हो सकती हो. उदाहरण के लिए, मोबाइल क्लाइंट ऐप्लिकेशन से अपलोड करते समय. इससे, नेटवर्क के काम न करने पर भी बैंडविड्थ का इस्तेमाल कम हो सकता है. ऐसा इसलिए, क्योंकि आपको शुरू से बड़े फ़ाइल अपलोड करने की ज़रूरत नहीं पड़ती.
फिर से शुरू किए जा सकने वाले अपलोड का इस्तेमाल करने के तरीके:
- फिर से शुरू करने वाला सेशन शुरू करें. अपलोड यूआरआई में शुरुआत में एक अनुरोध करें, जिसमें मेटाडेटा शामिल हो, अगर कोई हो.
- फिर से शुरू किए जाने वाले सेशन का यूआरआई सेव करें. शुरुआती अनुरोध के जवाब में वापस आए सेशन यूआरआई को सेव करें; आप इसका इस्तेमाल इस सेशन के बाकी अनुरोधों के लिए करेंगे.
- फ़ाइल अपलोड करें. मीडिया फ़ाइल को फिर से शुरू करने वाले सत्र यूआरआई में भेजें.
इसके अलावा, फिर से शुरू किए जा सकने वाले अपलोड का इस्तेमाल करने वाले ऐप्लिकेशन में कोड डालना ज़रूरी है, ताकि बिना रुकावट के अपलोड किया जा सके. अगर अपलोड करने में कोई रुकावट आ रही है, तो पता करें कि आपको कितना डेटा मिला है. इसके बाद, अपलोड को फिर से शुरू करें.
ध्यान दें: अपलोड यूआरआई की समयसीमा एक हफ़्ते की होती है.
पहला चरण: फिर से शुरू करने वाला सेशन शुरू करें
फिर से शुरू करने लायक अपलोड शुरू करने के लिए, तरीके के /upload यूआरआई में POST
या PUT
का अनुरोध करें और क्वेरी पैरामीटर
uploadType=resumable
जोड़ें, जैसे:
POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable
इस अनुरोध के लिए, मुख्य भाग खाली है या उसमें सिर्फ़ मेटाडेटा है. आप उस फ़ाइल का मूल कॉन्टेंट ट्रांसफ़र करेंगे जिसे आप बाद के अनुरोधों में अपलोड करना चाहते हैं.
शुरुआती अनुरोध के साथ इन एचटीटीपी हेडर का इस्तेमाल करें:X-Upload-Content-Type
: बाद के अनुरोधों में ट्रांसफ़र किए जाने वाले अपलोड डेटा के मीडिया MIME टाइप पर सेट करें.X-Upload-Content-Length
. बाद के अनुरोधों में ट्रांसफ़र किए जाने वाले अपलोड डेटा के बाइट की संख्या पर सेट करें. अगर अनुरोध करते समय इसकी लंबाई की जानकारी नहीं है, तो आप इस हेडर को छोड़ सकते हैं.- अगर मेटाडेटा दिया जा रहा है:
Content-Type
. मेटाडेटा के डेटा टाइप के हिसाब से सेट करें. Content-Length
. इस शुरुआती अनुरोध के मुख्य हिस्से में दी गई बाइट की संख्या पर सेट करें. अगर आप शेयर किए गए ट्रांसफ़र को कोड में बदलने का तरीका इस्तेमाल कर रहे हैं, तो यह ज़रूरी नहीं है.
हर तरीके का मीडिया MIME टाइप और अपलोड की गई फ़ाइलों के साइज़ की सीमा की सूची के लिए, एपीआई रेफ़रंस देखें.
उदाहरण: सेशन फिर से शुरू करने का अनुरोध
नीचे दिए गए उदाहरण में, Play की गेम सेवाओं को पब्लिश करने वाले एपीआई के लिए, फिर से शुरू करने वाले सेशन को शुरू करने का तरीका बताया गया है.
POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable HTTP/1.1 Host: www.googleapis.com Authorization: Bearer your_auth_token Content-Length: 38 Content-Type: application/json; charset=UTF-8 X-Upload-Content-Type: image/png X-Upload-Content-Length: 2000000 {
"kind": "gamesConfiguration#imageConfiguration",
"url": string,
"resourceId": string,
"imageType": string
}
ध्यान दें: मेटाडेटा के बिना, फिर से शुरू करने से जुड़े शुरुआती अनुरोध के लिए, अनुरोध के मुख्य हिस्से को खाली छोड़ दें. साथ ही, Content-Length
हेडर को 0
पर सेट करें.
अगले सेक्शन में, जवाब को मैनेज करने का तरीका बताया गया है.
चरण 2: फिर से शुरू करने वाले सत्र यूआरआई को सेव करें
अगर सेशन शुरू होने का अनुरोध पूरा हो जाता है, तो एपीआई सर्वर 200 OK
एचटीटीपी स्टेटस कोड के साथ जवाब देता है. साथ ही, यह Location
हेडर उपलब्ध कराता है, जो आपके फिर से शुरू किए जाने वाले सेशन यूआरआई के बारे में बताता है. यहां दिए गए उदाहरण में दिखाए गए Location
हेडर में, upload_id
क्वेरी पैरामीटर वाला हिस्सा शामिल है. इस सेशन में, इस्तेमाल करने के लिए यूनीक अपलोड आईडी दिया गया है.
उदाहरण: सेशन शुरू करने के लिए फिर से जवाब
यहां पहले चरण में किए गए अनुरोध का जवाब दिया गया है:
HTTP/1.1 200 OK Location: https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2 Content-Length: 0
जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है, Location
हेडर की वैल्यू वही सेशन यूआरआई है जिसका इस्तेमाल एचटीटीपी एंडपॉइंट के तौर पर किया जाएगा. इसका इस्तेमाल, असल फ़ाइल को अपलोड करने या अपलोड स्टेटस की क्वेरी करने के लिए किया जाएगा.
सेशन के यूआरआई को कॉपी करके सेव करें, ताकि आप बाद के अनुरोधों के लिए इसका इस्तेमाल कर सकें.
चरण 3: फ़ाइल अपलोड करें
फ़ाइल अपलोड करने के लिए, आपको पिछले चरण में मिले अपलोड यूआरआई को PUT
अनुरोध भेजें. अपलोड के अनुरोध का फ़ॉर्मैट इस तरह है:
PUT session_uri
फिर से शुरू किए जा सकने वाले फ़ाइल अपलोड के अनुरोध में इस्तेमाल किए जाने वाले एचटीटीपी हेडर में Content-Length
शामिल हैं. इसे उन बाइट की संख्या पर सेट करें जिन्हें आप इस अनुरोध में अपलोड कर रहे हैं, जो कि आम तौर पर फ़ाइल का अपलोड आकार होता है.
उदाहरण: फ़ाइल को फिर से अपलोड करने का अनुरोध
मौजूदा उदाहरण के लिए, पूरी 20,00,000 बाइट की PNG फ़ाइल अपलोड करने का अनुरोध फिर से शुरू किया जा सकता है.
PUT https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1 Content-Length: 2000000 Content-Type: image/png bytes 0-1999999
अनुरोध पूरा होने पर, सर्वर के साथ HTTP 201 Created
संसाधन का रिस्पॉन्स देता है. अगर फिर से शुरू किए जा सकने वाले सेशन का शुरुआती अनुरोध PUT
था, तो किसी मौजूदा संसाधन को अपडेट करने के लिए, 200 OK
का जवाब दिया जाएगा. साथ ही, इस संसाधन से जुड़े सभी मेटाडेटा भी शामिल होंगे.
अगर अपलोड करने में कोई रुकावट आ रही है या आपको सर्वर से HTTP 503 Service Unavailable
या कोई दूसरा 5xx
रिस्पॉन्स मिला है, तो अपलोड होने की प्रोसेस फिर से शुरू करें में बताया गया तरीका अपनाएं.
फ़ाइल को हिस्सों में अपलोड करना
फिर से शुरू किए जा सकने वाले अपलोड की मदद से, किसी फ़ाइल को अलग-अलग हिस्सों में बांटा जा सकता है. साथ ही, हर हिस्से को क्रम से अपलोड करने के लिए, कई अनुरोध भेजे जा सकते हैं. यह दूसरा तरीका नहीं है, क्योंकि अलग-अलग अनुरोधों की परफ़ॉर्मेंस से जुड़ी लागतें शामिल हैं और आम तौर पर इसकी ज़रूरत नहीं होती. हालांकि, किसी एक अनुरोध में ट्रांसफ़र किए गए डेटा को कम करने के लिए, आपको चंकिंग का इस्तेमाल करना पड़ सकता है. यह अलग-अलग अनुरोधों के लिए तय समय सीमा होने पर, Google App Engine अनुरोधों की कुछ खास क्लास के लिए सही होता है. इसकी मदद से, पुराने ब्राउज़र के लिए अपलोड की स्थिति बताने वाले टूल भी इस्तेमाल किए जा सकते हैं. इनमें, डिफ़ॉल्ट रूप से, अपलोड की प्रोसेस को आगे बढ़ाने से जुड़ी सहायता मौजूद नहीं होती है.
रुकावट वाले अपलोड को फिर से शुरू करना
अगर जवाब पाने से पहले अपलोड का अनुरोध बंद कर दिया जाता है या आपको सर्वर से एचटीटीपी का 503 Service Unavailable
जवाब मिलता है, तो आपको अपलोड करने की प्रोसेस फिर से शुरू करने की ज़रूरत होगी. ऐसा करने के लिए:
- अनुरोध की स्थिति. अपलोड यूआरआई को खाली
PUT
अनुरोध जारी करके, अपलोड की मौजूदा स्थिति के बारे में क्वेरी करें. इस अनुरोध के लिए, एचटीटीपी हेडर मेंContent-Range
हेडर शामिल होना चाहिए. इससे पता चलता है कि फ़ाइल में मौजूदा जगह के बारे में कोई जानकारी नहीं है. उदाहरण के लिए, अगर आपकी फ़ाइल की कुल लंबाई 2,000,000 है, तोContent-Range
को*/2000000
पर सेट करें. अगर आपको फ़ाइल का पूरा साइज़ नहीं पता है, तोContent-Range
को*/*
पर सेट करें.ध्यान दें: आप डेटा के अलग-अलग हिस्सों के बीच स्टेटस का अनुरोध कर सकते हैं, न कि सिर्फ़ तब, जब अपलोड में रुकावट आ रही हो. उदाहरण के लिए, यह तरीका तब काम आता है, जब आपको लेगसी ब्राउज़र के लिए, अपलोड की स्थिति बताने वाले संकेत दिखाने हैं.
- अपलोड किए गए बाइट की संख्या जानें. स्थिति वाली क्वेरी से मिले जवाब को प्रोसेस करें. यह बताने के लिए कि सर्वर को अब तक कौनसे बाइट मिले हैं,
Range
हेडर का इस्तेमाल करता है. उदाहरण के लिए,0-299999
काRange
हेडर यह बताता है कि फ़ाइल के शुरुआती 3,00,000 बाइट मिल चुके हैं. - बाकी डेटा अपलोड करें. आखिर में, अब जब आपको पता है कि अनुरोध को फिर से शुरू करना है, तो बाकी डेटा या उसका डेटा भेजें. ध्यान दें कि किसी भी मामले में, आपको बाकी डेटा को एक अलग हिस्से के तौर पर रखना होगा, इसलिए अपलोड फिर से शुरू करते समय आपको
Content-Range
हेडर भेजना होगा.
उदाहरण: किसी अपलोड को फिर से शुरू करना
1) अपलोड की स्थिति का अनुरोध करें.
यहां दिया गया अनुरोध, Content-Range
हेडर का इस्तेमाल करके यह बताता है कि 20,00,000 बाइट की मौजूदा फ़ाइल के बारे में कोई जानकारी नहीं है.
PUT {session_uri} HTTP/1.1 Content-Length: 0 Content-Range: bytes */2000000
2) जवाब से अब तक अपलोड की गई बाइट की संख्या निकालें.
सर्वर का रिस्पॉन्स यह बताने के लिए Range
हेडर का इस्तेमाल करता है कि उसे अब तक फ़ाइल की पहली 43 बाइट मिल चुकी हैं. यह तय करने के लिए कि फिर से शुरू किया गया अपलोड कहां से शुरू करें, Range
हेडर की ऊपरी वैल्यू का इस्तेमाल करें.
HTTP/1.1 308 Resume Incomplete Content-Length: 0 Range: 0-42
ध्यान दें: अपलोड पूरा होने पर, स्टेटस के तौर पर जवाब 201 Created
या 200 OK
हो सकते हैं. ऐसा तब हो सकता है, जब सभी बाइट अपलोड होने के बाद कनेक्शन टूट गया हो, लेकिन क्लाइंट को सर्वर से जवाब मिलने से पहले.
3) अपलोड को वहीं से शुरू करें जहां आपने उसे छोड़ा था.
अनुरोध बाइट 43 से शुरू करते हुए, फ़ाइल के बचे हुए बाइट भेजकर अपलोड फिर से शुरू करता है.
PUT {session_uri} HTTP/1.1 Content-Length: 1999957 Content-Range: bytes 43-1999999/2000000 bytes 43-1999999
सबसे सही तरीके
मीडिया अपलोड करते समय, गड़बड़ी को ठीक करने से जुड़े कुछ सबसे सही तरीकों के बारे में जानकारी रखना मददगार होता है.
- कनेक्शन में रुकावट या
5xx
की किसी गड़बड़ी की वजह से, अपलोड न हो पाने की फिर से कोशिश करें या अपलोड करने की कोशिश करें. इनमें ये गड़बड़ियां शामिल हैं:500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
- अपलोड अनुरोध फिर से शुरू करते समय या फिर से प्रयास करते समय कोई
5xx
सर्वर गड़बड़ी मिलने पर घातांकीय बैकऑफ़ कार्यनीति का उपयोग करें. ये गड़बड़ियां तब हो सकती हैं, जब सर्वर पर ओवरलोड हो गया हो. बहुत ज़्यादा अनुरोधों या बहुत ज़्यादा नेटवर्क ट्रैफ़िक के दौरान, बहुत ज़्यादा देर तक बैकऑफ़ रहने से इस तरह की समस्याओं को कम करने में मदद मिल सकती है. - दूसरे तरह के अनुरोध, एक्सपोनेंशियल बैकऑफ़ से नहीं मैनेज किए जा सकते. हालांकि, आप अब भी उनमें से कई अनुरोधों को फिर से आज़माने की कोशिश कर सकते हैं. इन अनुरोधों के लिए फिर से कोशिश करते समय, सीमित करें कि आप ये बार-बार ही कोशिश करें. उदाहरण के लिए, किसी गड़बड़ी की रिपोर्ट करने से पहले आपका कोड 10 बार या उससे कम बार कोशिश कर सकता है.
- शुरू से दोबारा अपलोड शुरू करके दोबारा शुरू करने लायक सामग्री बनाते समय
404 Not Found
और410 Gone
गड़बड़ियों को ठीक करें.
घातांकीय बैकऑफ़
एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी को हैंडल करने की एक स्टैंडर्ड रणनीति है. इसमें क्लाइंट समय-समय पर बार-बार अनुरोध पूरा नहीं कर पाता है. अगर ज़्यादा अनुरोधों या बहुत ज़्यादा नेटवर्क ट्रैफ़िक की वजह से सर्वर से गड़बड़ियां मिलती हैं, तो एक्सपोनेंशियल बैकऑफ़ की मदद से इन गड़बड़ियों को ठीक किया जा सकता है. इसके उलट, यह उन गड़बड़ियों से निपटने के लिए सही रणनीति नहीं है जो नेटवर्क के वॉल्यूम या जवाब देने के समय से जुड़ी नहीं है. जैसे, अमान्य ऑथराइज़ेशन क्रेडेंशियल या फ़ाइल नहीं मिलने की गड़बड़ियां.
सही तरीके से इस्तेमाल करने पर, एक्सपोनेन्शियल बैकऑफ़ बैंडविड्थ के इस्तेमाल को बेहतर बनाता है. साथ ही, सही रिस्पॉन्स पाने के लिए ज़रूरी अनुरोधों की संख्या भी कम करता है और मिलते-जुलते एनवायरमेंट में अनुरोधों के थ्रूपुट को ज़्यादा से ज़्यादा बढ़ाता है.
सरल एक्सपोनेन्शियल बैकऑफ़ लागू करने का प्रवाह इस प्रकार है:
- एपीआई को अनुरोध भेजें.
HTTP 503
का जवाब पाएं. इससे यह पता चलता है कि आपको फिर से अनुरोध करना है.- 1 सेकंड + रैंडम_नंबर_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
HTTP 503
का जवाब पाएं. इससे यह पता चलता है कि आपको फिर से अनुरोध करना है.- दो सेकंड से ज़्यादा इंतज़ार करें और रैंडम_नंबर_मिलीसेकंड के बाद अनुरोध करें.
HTTP 503
का जवाब पाएं. इससे यह पता चलता है कि आपको फिर से अनुरोध करना है.- चार सेकंड तक इंतज़ार करें, रैंडम कोड में मिलीसेकंड तक और फिर से अनुरोध करने की कोशिश करें.
HTTP 503
का जवाब पाएं. इससे यह पता चलता है कि आपको फिर से अनुरोध करना है.- 8 सेकंड + रैंडम_नंबर_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
HTTP 503
का जवाब पाएं. इससे यह पता चलता है कि आपको फिर से अनुरोध करना है.- 16 सेकंड + रैंडम_नंबर_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
- वीडियो बंद करने के लिए. गड़बड़ी की शिकायत करें या लॉग करें.
ऊपर दिए गए फ़्लो में, रैंडम_नंबर_मिलीसेकंड 1000 से कम या उसके बराबर मिलीसेकंड की एक रैंडम संख्या है. यह ज़रूरी है, क्योंकि थोड़ी सी भी देरी होने से, लोड को ज़्यादा समान रूप से डिस्ट्रिब्यूट करने और सर्वर पर स्टैंप करने की संभावना से बचा जा सकता है. हर इंतज़ार के बाद, रैंडम_नंबर_मिलीसेकंड का मान फिर से तय करना चाहिए.
ध्यान दें: इंतज़ार हमेशा (2 ^ n) + रैंडम_नंबर_मिली सेकंड, जहां n एक मोनोनॉटिक रूप से बढ़ता हुआ पूर्णांक होता है जिसे शुरू में 0 के रूप में तय किया जाता है. हर बार दोहराने (हर अनुरोध) के लिए, पूर्णांक n में 1 की बढ़ोतरी की जाती है.
एल्गोरिदम, n पांच पर खत्म होने के लिए सेट है. यह सीमा क्लाइंट को अनिश्चित रूप से फिर से कोशिश करने से रोकती है और अनुरोध की स्थिति में "ठीक नहीं की जा सकने वाली गड़बड़ी" के पहले करीब 32 सेकंड की देरी होती है. इससे ज़्यादा बार कोशिश नहीं की जा सकती, खास तौर पर तब, जब किसी लंबे वीडियो को अपलोड करने की प्रोसेस चल रही हो. कोशिश करें कि एक मिनट से भी कम समय में, फिर से कोशिश करने पर देरी हो.