पैकेज बनाएं

अपलोड के विकल्प

Android Over The Air API आपको पैकेज डेटा अपलोड करने देता है, ताकि आप नया पैकेज रिसॉर्स बना सकें. ये हैं ऐसे ओटीए पैकेज जिन्हें एक या उससे ज़्यादा कॉन्फ़िगरेशन के साथ जोड़ा जा सकता है, ताकि अपडेट डिलीवर किया जा सके किस तरह ऐक्सेस कर सकते हैं.

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

ध्यान दें: ये बाइनरी हमारे नियम के अनुसार बिना सहायता के दिए गए हैं सेवा की शर्तें.

Linux

Linux के लिए Android Over The Air API v1 अपलोडर क्लाइंट डाउनलोड करें.

Windows

Windows के लिए, Android Over The Air API v1 अपलोडर क्लाइंट डाउनलोड करें.

इसका इस्तेमाल करने के लिए, आपको सबसे पहले सेवा खाता बनाना होगा और उस खाते के लिए JSON कुंजी वाली फ़ाइल लेनी होगी. कृपया खाता बनाने के लिए यहां हमारी गाइड देखें.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है आपके पास बाइनरी और कुंजी फ़ाइल होने के बाद, उसे कमांड लाइन के विकल्पों की मदद से चलाया जा सकता है, ताकि कुंजी फ़ाइल, आपका परिनियोजन और वह पैकेज जिसे आप अपलोड कर रहे हैं. कृपया --help का इस्तेमाल करें क्लिक करके सभी विकल्प देखें.

प्रोटोकॉल अपलोड करें

इनमें से किसी भी तरीके से, डेटा अपलोड करने का अनुरोध किया जा सकता है. X-Goog-Upload-Protocol अनुरोध के हेडर के साथ इस्तेमाल किया जा रहा तरीका बताएं.

• कई हिस्सों में अपलोड करना: X-Goog-Upload-Protocol: multipart. के छोटी फ़ाइलें और मेटाडेटा; फ़ाइल को एक ही अनुरोध में, उसके बारे में जानकारी देने वाले मेटाडेटा के साथ ट्रांसफ़र करता है.
• फिर से अपलोड किया जा सकता है: X-Goog-Upload-Protocol: resumable. ट्रांसफ़र का भरोसेमंद तरीका, खास तौर पर बड़े साइज़ के ट्रांसफ़र के लिए फ़ाइलें शामिल हैं. इस तरीके में, सेशन शुरू करने के अनुरोध का इस्तेमाल किया जाता है. इसमें मेटाडेटा भी शामिल किया जा सकता है. ज़्यादातर उपयोगकर्ताओं के लिए यह रणनीति अच्छी है है, क्योंकि यह छोटी फ़ाइलों के लिए भी काम करता है. इसके लिए, हर अपलोड के लिए एक अतिरिक्त एचटीटीपी अनुरोध देना पड़ता है.

एक से ज़्यादा हिस्सों वाला अपलोड

अगर भेजा जा रहा डेटा कम है, तो यह एक अच्छा विकल्प है अगर कनेक्शन टूट जाता है, तो इसे फिर से अपलोड करना काफ़ी फ़ायदेमंद होता है.

एक से ज़्यादा हिस्सों वाले अपलोड का इस्तेमाल करने के लिए, /upload/package के लिए POST का अनुरोध करें यूआरआई और X-Goog-Upload-Protocol को multipart पर सेट करें.

एक से ज़्यादा हिस्सों वाले अपलोड का अनुरोध करते समय, इन टॉप लेवल एचटीटीपी हेडर का इस्तेमाल किया जाएगा:

• Content-Type. एक से ज़्यादा हिस्से/मिलते-जुलते पर सेट करें और अपनी सीमा वाली स्ट्रिंग को शामिल करें का इस्तेमाल करके अनुरोध के अलग-अलग हिस्सों की पहचान की जाती है.
• Content-Length. अनुरोध के मुख्य हिस्से में बाइट की कुल संख्या पर सेट करें.

अनुरोध के मुख्य हिस्से को multipart/related कॉन्टेंट के तौर पर फ़ॉर्मैट किया गया है [RFC2387] टाइप करें और इसमें सिर्फ़ दो हिस्से शामिल होते हैं. हिस्सों की पहचान सीमा स्ट्रिंग से की जाती है और आखिरी सीमा वाली स्ट्रिंग के बाद दो हाइफ़न होते हैं.

एक से ज़्यादा हिस्सों वाले अनुरोध के हर हिस्से के लिए एक अतिरिक्त Content-Type हेडर होना चाहिए:

1. मेटाडेटा का हिस्सा: पहले आना चाहिए और Content-Type application/json होना चाहिए.
2. मीडिया का हिस्सा: सेकंड वाला हिस्सा होना चाहिए और Content-Type, application/zip होना चाहिए.

उदाहरण: एक से ज़्यादा हिस्सों वाला अपलोड

नीचे दिया गया उदाहरण Android Over The Air API के लिए, एक से ज़्यादा हिस्सों में अपलोड करने का अनुरोध दिखाता है.

POST /upload/package HTTP/1.1
Host: androidovertheair.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=BOUNDARY
Content-Length: number_of_bytes_in_entire_request_body

--BOUNDARY
Content-Type: application/json; charset=UTF-8

{"deployment": "id", "package_title": "title" }
--BOUNDARY
Content-Type: application/zip; charset=UTF-8

Package ZIP
--BOUNDARY--

अगर अनुरोध पूरा होता है, तो सर्वर एचटीटीपी 200 OK स्टेटस कोड दिखाता है

HTTP/1.1 200

इसे आसानी से पूरा करने का तरीका है, curl का इस्तेमाल करना और oauth2l. अनुरोध का एक सैंपल नीचे दिया गया है तो यह मान लिया जाता है कि आप सेवा कुंजी का इस्तेमाल कर रहे हैं (हमारी नीति पढ़ें अनुमति देने का तरीका देखें).

कर्ल अनुरोध का उदाहरण

    JSON={"deployment": "id", "package_title": "title" }
    SERVICE_KEY_FILE=path to your service key json file
    curl \
    -H "$(./oauth2l header --json $SERVICE_KEY_FILE android_partner_over_the_air)" \
    -H "Host: androidovertheair.googleapis.com" \
    -H "X-Goog-Upload-Protocol: multipart" \
    -H "Content-Type: multipart/form-data" \
    -F "json=$JSON;type=application/json" \
    -F "data=@update.zip;type=application/zip" \
    androidovertheair.googleapis.com/upload/package
  

फिर से अपलोड किया जा सकता है

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

फिर से शुरू किए जा सकने वाले अपलोड प्रोटोकॉल में कई निर्देशों का इस्तेमाल होता है:

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

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

ध्यान दें: अपलोड यूआरआई तीन दिनों के बाद काम नहीं करता.

पहला चरण: फिर से शुरू किया जा सकने वाला सेशन शुरू करना

फिर से शुरू किए जा सकने वाले अपलोड को शुरू करने के लिए, /upload/package से POST का अनुरोध करें यूआरआई और X-Goog-Upload-Protocol को resumable पर सेट करें.

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

शुरुआती अनुरोध के साथ, यहां दिए गए एचटीटीपी हेडर इस्तेमाल करें:

• X-Goog-Upload-Header-Content-Type. यह अपलोड की जा रही फ़ाइल का कॉन्टेंट टाइप है. इसे application/zip पर सेट किया जाना चाहिए.
• X-Goog-Upload-Command. start पर सेट करें
• X-Goog-Upload-Header-Content-Length. बाद के अनुरोधों में ट्रांसफ़र किए जाने वाले अपलोड डेटा के बाइट की संख्या पर सेट करें. अगर अनुरोध करते समय लंबाई की जानकारी नहीं है, तो इस हेडर को छोड़ा जा सकता है.
• Content-Type. यह मेटाडेटा का कॉन्टेंट टाइप है. इसे application/json पर सेट किया जाना चाहिए.
• Content-Length. इस शुरुआती अनुरोध के मुख्य भाग में दी गई बाइट की संख्या पर सेट करें.

उदाहरण: सेशन को फिर से शुरू करने का अनुरोध

नीचे दिए गए उदाहरण में, Android Over The Air API के लिए फिर से शुरू किए जा सकने वाले सेशन को शुरू करने का तरीका बताया गया है.

POST /upload/package HTTP/1.1
Host: android/over-the-air.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Goog-Upload-Command: start
X-Goog-Upload-Header-Content-Type: application/zip
X-Goog-Upload-Header-Content-Length: 2000000

{"deployment": "id", "package_title": "title" }

अगले सेक्शन में, रिस्पॉन्स को मैनेज करने का तरीका बताया गया है.

दूसरा चरण: फिर से शुरू किए जा सकने वाले सेशन के यूआरआई को सेव करें

अगर सेशन शुरू करने का अनुरोध पूरा हो जाता है, तो एपीआई सर्वर एक एचटीटीपी 200 OK स्टेटस कोड के साथ जवाब देता है. इसके अलावा, यह एक X-Goog-Upload-URL हेडर उपलब्ध कराता है, जो फिर से शुरू किए जा सकने वाले आपके सेशन यूआरआई के बारे में बताता है. नीचे दिए गए उदाहरण में दिखाए गए X-Goog-Upload-URL हेडर में, upload_id क्वेरी पैरामीटर शामिल है वह हिस्सा है, जो इस सत्र के लिए उपयोग के लिए विशेष अपलोड आईडी देता है. जवाब में एक X-Goog-Upload-Status भी शामिल है हेडर, जो अपलोड करने का अनुरोध मान्य और स्वीकार होने पर active होगा. स्टेटस final हो सकता है अगर अपलोड अस्वीकार कर दिया गया था.

उदाहरण: फिर से शुरू किए जा सकने वाले सेशन शुरू करने का जवाब

यहां पहले चरण में अनुरोध का जवाब दिया गया है:

HTTP/1.1 200 OK
X-Goog-Upload-Status: active
X-Goog-Upload-URL: androidovertheair.googleapis.com/?upload_id=xa298sd_sdlkj2
Content-Length: 0

ऊपर दिए गए उदाहरण के मुताबिक, X-Goog-Upload-URL हेडर की वैल्यू यह है सेशन यूआरआई को असल फ़ाइल अपलोड करने या अपलोड स्टेटस की क्वेरी करने के लिए, एचटीटीपी एंडपॉइंट के तौर पर इस्तेमाल किया जाएगा.

सेशन यूआरआई को कॉपी करें और सेव करें, ताकि आप इसका इस्तेमाल बाद के अनुरोधों के लिए कर सकें.

चरण 3: फ़ाइल अपलोड करें

फ़ाइल अपलोड करने के लिए, उस अपलोड यूआरआई पर POST अनुरोध भेजें जो आपको पिछला चरण. फ़ाइल अपलोड करने के अनुरोध का फ़ॉर्मैट:

POST session_uri

फिर से शुरू किए जाने योग्य फ़ाइल अपलोड अनुरोध करते समय उपयोग किए जाने वाले HTTP हेडर में ये शामिल हैं:

1. Content-Length. इसे इस अनुरोध में अपलोड किए जाने वाले बाइट की संख्या पर सेट करें, जो आम तौर पर अपलोड की जाने वाली फ़ाइल का साइज़ होता है.
2. X-Goog-Upload-Command. इसे upload और finalize पर सेट करें.
3. X-Goog-Upload-Offset. यह उस ऑफ़सेट को तय करता है जिस पर बाइट लिखे जाने चाहिए. ध्यान दें कि क्लाइंट बाइट को क्रम से अपलोड करना चाहिए.

उदाहरण: फ़ाइल अपलोड करने का अनुरोध फिर से शुरू किया जा सकता है

यहां दिए गए उदाहरण के मुताबिक, पूरी 20,00,000 बाइट वाली ZIP फ़ाइल को अपलोड करने के लिए, फिर से शुरू किया जा सकने वाला अनुरोध यहां दिया गया है.

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Protocol: resumable
X-Goog-Upload-Command: upload, finalize
X-Goog-Upload-Offset: 0
Content-Length: 2000000
Content-Type: application/zip

bytes 0-1999999

अगर अनुरोध पूरा होता है, तो सर्वर एचटीटीपी 200 Ok के साथ जवाब देता है.

अगर अपलोड करने के अनुरोध में रुकावट आती है या आपको एचटीटीपी 503 Service Unavailable या कोई ऐसा मैसेज मिलता है सर्वर से मिले अन्य 5xx रिस्पॉन्स के लिए, रुका हुआ अपलोड फिर से शुरू करें में बताई गई प्रक्रिया अपनाएं.

---

फ़ाइल को हिस्सों में अपलोड करना

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

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

ज़्यादा जानकारी के लिए बड़ा करें

अगर डेटा को हिस्सों में अपलोड किया जा रहा है, तो X-Goog-Upload-Offset का इस्तेमाल करके, उस ऑफ़सेट के बारे में बताएं जिसे अपलोड किया जा रहा है.

• Content-Length. डेटा को डेटा सेगमेंट पर या उससे कम पर सेट करें. ऐसा पिछले अनुरोध के मामले में भी हो सकता है.
• X-Goog-Upload-Offset. यह उस ऑफ़सेट को तय करता है जिस पर बाइट लिखे जाने चाहिए. ध्यान दें कि क्लाइंट बाइट को क्रम से अपलोड करना चाहिए.

अलग-अलग साइज़ की पाबंदी: सर्वर, X-Goog-Upload-Chunk-Granularity हेडर की मदद से जवाब दे सकता है जो क्लाइंट की ओर से भेजे गए सभी हिस्से के बाइट अलाइनमेंट और आकार की जानकारी को तय करता है. सभी हिस्से ऑफ़सेट के हिसाब से इस हेडर की वैल्यू के साथ अलाइन होता है. साथ ही, सभी हिस्से (आखिरी हिस्से को छोड़कर) के लिए ऐसा साइज़ होना चाहिए जो हेडर को हाइलाइट करें. अगर सर्वर ने हेडर नहीं दिया है, तो अलाइनमेंट या जानकारी के लेवल की कोई शर्त मौजूद नहीं है.

उदाहरण: कई फ़ाइलों को अपलोड करने के अनुरोध को फिर से शुरू किया जा सकता है

पहली 5,24,288 बाइट भेजने वाला अनुरोध कुछ ऐसा दिख सकता है:

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Command: upload
X-Goog-Upload-Offset: 0
Content-Type: application/zip
Content-Length: 524288

bytes 0-524288

अगर अनुरोध पूरा होता है, तो सर्वर एचटीटीपी 200 Ok के साथ जवाब देता है.

अगर किसी ग्रुप के PUT अनुरोध में रुकावट आती है या आपको एचटीटीपी 503 Service Unavailable मिलता है या सर्वर से मिले किसी अन्य 5xx रिस्पॉन्स के लिए, फिर से शुरू करें' में बताई गई प्रोसेस का पालन करें अपलोड करने में रुकावट आती है, लेकिन बाकी फ़ाइल अपलोड करने के बजाय, सीधे उसके हिस्से अपलोड करें.

ज़रूरी जानकारी:

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

जब फ़ाइल का पूरा अपलोड पूरा हो जाता है, तो सर्वर, एचटीटीपी 200 Ok के साथ रिस्पॉन्स के तौर पर X-Goog-Upload-Status को final पर सेट किया गया.

---

जो अपलोड पूरा नहीं हुआ उसे फिर से शुरू करें

अगर कोई अनुरोध, जवाब मिलने से पहले ही रद्द कर दिया जाता है या सर्वर से एचटीटीपी 503 Service Unavailable रिस्पॉन्स मिला है, तो आपको बीच में रोके गए अपलोड को फिर से शुरू करना होगा. ऐसा करने के लिए:

1. अनुरोध की स्थिति. अपलोड यूआरआई को अनुरोध जारी करके, अपलोड की मौजूदा स्थिति के बारे में क्वेरी करें जिसमें X-Goog-Upload-Command को query पर सेट किया गया हो.

   ध्यान दें: अगर अपलोड में रुकावट आ रही हो, तो भी डेटा को अलग-अलग हिस्सों में बांटने का अनुरोध किया जा सकता है. यह है उपयोगी है, उदाहरण के लिए, अगर आपको लेगसी ब्राउज़र के लिए, अपलोड की स्थिति के संकेत दिखाना हो.

2. जानें कि कितने बाइट अपलोड किए गए. स्टेटस क्वेरी का जवाब प्रोसेस करें. सर्वर, X-Goog-Upload-Size-Received हेडर, जिससे यह पता चलता है कि उसे अब तक कितने बाइट मिल चुके हैं.
3. बचा हुआ डेटा अपलोड करें. अंत में, अब आपको पता है कि अनुरोध को कहां से दोबारा शुरू करना है, तो बचा हुआ डेटा या मौजूदा डेटा ग्रुप. ध्यान दें कि आपको बाकी बचे डेटा को दोनों में से किसी भी स्थिति में एक अलग डेटा समूह के रूप में इस्तेमाल करना होगा, इसलिए अपलोड को फिर से शुरू करते समय, आपको X-Goog-Upload-Offset हेडर को सही ऑफ़सेट पर सेट करना होगा.

उदाहरण: किसी रुकावट अपलोड होने की प्रोसेस को फिर से शुरू करना

1) अपलोड की स्थिति के लिए अनुरोध करें.

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Command: query

सभी निर्देशों की तरह ही, क्लाइंट को किसी क्वेरी कमांड के एचटीटीपी रिस्पॉन्स में X-Goog-Upload-Status हेडर की जांच करनी होगी. अगर हेडर मौजूद है और वैल्यू active नहीं है, तो इसका मतलब है कि अपलोड पहले ही खत्म किया जा चुका है.

2) रिस्पॉन्स से अब तक अपलोड की गई बाइट की संख्या निकालें.

सर्वर का रिस्पॉन्स, X-Goog-Upload-Size-Received हेडर का इस्तेमाल करके बताता है कि उसमें फ़ाइल की अब तक के पहले 43 बाइट प्राप्त हुए हैं.

HTTP/1.1 200 OK
X-Goog-Upload-Status: active
X-Goog-Upload-Size-Received: 42

3) अपलोड को वहीं से दोबारा शुरू करें जहां उसे छोड़ा गया था.

नीचे दिया गया अनुरोध, बाइट 43 से शुरू होने वाली फ़ाइल की बाकी बाइट भेजकर अपलोड को फिर से शुरू करता है.

POST /?upload_id=xa298sd_sdlkj2 HTTP/1.1
Host: androidovertheair.googleapis.com
X-Goog-Upload-Command: upload, finalize
Content-Length: 1999957
X-Goog-Upload-Offset: 43

bytes 43-1999999

सबसे सही तरीके

मीडिया अपलोड करते समय, गड़बड़ियों को ठीक करने के कुछ सबसे सही तरीके जानें.

• कनेक्शन से जुड़ी रुकावटों या 5xx की गड़बड़ियों की वजह से अपलोड न हो पाने वाले वीडियो, फिर से अपलोड करें या उन्हें फिर से अपलोड करने की कोशिश करें. इनमें ये शामिल हैं:
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
• अगर अपलोड अनुरोधों को फिर से शुरू करने या फिर से कोशिश करते समय 5xx सर्वर की कोई गड़बड़ी मिलती है, तो एक्सपोनेन्शियल बैकऑफ़ रणनीति का इस्तेमाल करें. ये गड़बड़ियां तब हो सकती हैं, जब सर्वर पर ज़रूरत से ज़्यादा लोड हो. एक्सपोनेन्शियल बैकऑफ़ से अनुरोधों की ज़्यादा संख्या या बहुत ज़्यादा नेटवर्क ट्रैफ़िक के दौरान इस तरह की समस्याओं से बचने में मदद मिल सकती है.
• अन्य तरह के अनुरोधों को एक्स्पोनेंशियल बैकऑफ़ के ज़रिए हैंडल नहीं किया जाना चाहिए, लेकिन फिर भी उनमें से कई अनुरोधों को हैंडल करने की कोशिश की जा सकती है. इन अनुरोधों की फिर से कोशिश करते समय, उन्हें फिर से करने की संख्या सीमित करें. उदाहरण के लिए, आपके कोड में गड़बड़ी की शिकायत करने से पहले, यह सीमा 10 या इससे कम बार हो सकती है.
• शुरुआत से पूरे अपलोड को फिर से शुरू करके, फिर से शुरू किए जा सकने वाले अपलोड करते समय 404 Not Found गड़बड़ियों को हल करें.

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

एक्स्पोनेंशियल बैकऑफ़, उन नेटवर्क ऐप्लिकेशन के लिए गड़बड़ियों को मैनेज करने की स्टैंडर्ड रणनीति है जिनमें क्लाइंट समय-समय पर, अनुरोध पूरा न होने पर फिर से अनुरोध करता है. अगर अनुरोधों की ज़्यादा संख्या या नेटवर्क ट्रैफ़िक की वजह से सर्वर गड़बड़ियां देता है, तो उन गड़बड़ियों से निपटने के लिए एक्स्पोनेंशियल बैकऑफ़ एक अच्छी रणनीति हो सकती है. इसके ठीक उलट, यह तरीका नेटवर्क वॉल्यूम या जवाब देने में लगने वाले समय से जुड़ी गड़बड़ियों से निपटने के लिए सही रणनीति नहीं है. जैसे, पुष्टि करने के अमान्य क्रेडेंशियल या फ़ाइल नहीं मिलने से जुड़ी गड़बड़ियां.

सही तरीके से इस्तेमाल किए जाने पर, एक्स्पोनेंशियल बैकऑफ़, बैंडविथ के इस्तेमाल की क्षमता को बढ़ाता है, सफल जवाब पाने के लिए ज़रूरी अनुरोधों की संख्या को कम करता है, और एक साथ काम करने वाले एनवायरमेंट में अनुरोधों की संख्या बढ़ाता है.

सिंपल एक्स्पोनेंशियल बैकऑफ़ लागू करने का फ़्लो यह है:

1. एपीआई को अनुरोध भेजें.
2. HTTP 503 रिस्पॉन्स पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
3. एक सेकंड और रैंडम_number_मिलीसेकंड तक इंतज़ार करें. इसके बाद, फिर से अनुरोध करने की कोशिश करें.
4. HTTP 503 रिस्पॉन्स पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
5. दो सेकंड और रैंडम_number_मिलीसेकंड से इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
6. HTTP 503 रिस्पॉन्स पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
7. चार सेकंड और रैंडम_number_मिलीसेकंड तक इंतज़ार करें और फिर से अनुरोध करें.
8. HTTP 503 रिस्पॉन्स पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
9. आठ सेकंड + रैंडम_number_मिलीसेकंड से इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
10. HTTP 503 रिस्पॉन्स पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
11. 16 सेकंड और रैंडम नंबर_मिलीसेकंड से ज़्यादा इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
12. बंद करो। गड़बड़ी की शिकायत करें या लॉग इन करें.

ऊपर दिए गए फ़्लो में, रैंडम_number_मिलीसेकंड 1,000 से कम या उसके बराबर मिलीसेकंड की एक रैंडम संख्या है. यह इसलिए ज़रूरी है, क्योंकि किसी भी क्रम में लगने वाले समय में थोड़ी देर शुरू करने से, लोड को ज़्यादा समान रूप से बांटने में मदद मिलती है. साथ ही, सर्वर पर स्टैंप लगाने की संभावना भी कम हो जाती है. हर इंतज़ार के बाद, रैंडम_number_मिलीसेकंड की वैल्यू फिर से तय करनी होगी.

ध्यान दें: इंतज़ार हमेशा (2 ^ n) + रैंडम_number_मिलीसेकंड होता है, जहां n एक क्रमिक रूप से बढ़ने वाला पूर्णांक है, जिसे शुरुआत में 0 के तौर पर दिखाया जाता है. हर अनुरोध (हर अनुरोध) के लिए, पूर्णांक n की वैल्यू 1 से बढ़ती है.

n होने पर एल्गोरिदम खत्म हो जाता है. यह सेटिंग, क्लाइंट को कई बार कोशिश करने से रोकती है. साथ ही, किसी अनुरोध को "ठीक नहीं किया जा सकने वाली गड़बड़ी" माने जाने से पहले, करीब 32 सेकंड की देरी हो जाती है. ज़्यादा से ज़्यादा संख्या में कोशिश करने से फ़ायदा हो सकता है. खास तौर पर तब, जब बहुत लंबा वीडियो अपलोड हो रहा हो; कृपया ध्यान रखें कि फिर से कोशिश करने के लिए, एक मिनट से कम का समय दिया गया हो.