मीडिया अपलोड करने के बारे में जानकारी

Google मिरर एपीआई आपको नया टाइमलाइन आइटम बनाते समय अटैचमेंट जोड़ने की सुविधा देता है.

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

Google Mirror API की मदद से, कुछ खास तरह के बाइनरी डेटा या मीडिया को अपलोड किया जा सकता है. मीडिया अपलोड की सुविधा देने वाले किसी भी तरीके के लिए, पहचान की जानकारी देने वाले पेज पर, आपके अपलोड किए गए डेटा की खास जानकारी दी गई है:

• अपलोड की जाने वाली फ़ाइल का साइज़: ज़्यादा से ज़्यादा कितना डेटा सेव किया जा सकता है.
• स्वीकार किए जाने वाले MIME टाइप: ऐसे बाइनरी डेटा के टाइप जिन्हें इस तरीके से सेव किया जा सकता है.

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

• अपलोड करने में आसान: uploadType=media. छोटी फ़ाइलों को तुरंत ट्रांसफ़र करने के लिए, जैसे कि 5 एमबी या इससे कम.
• मल्टीपार्ट अपलोड: uploadType=multipart. छोटी फ़ाइलों और मेटाडेटा को तुरंत ट्रांसफ़र करने के लिए, फ़ाइल को मेटाडेटा के साथ ट्रांसफ़र करें. इससे, वह मेटाडेटा एक ही अनुरोध में ट्रांसफ़र हो जाता है.
• फिर से अपलोड किया जा सकता है: uploadType=resumable. फ़ाइलों का भरोसेमंद ट्रांसफ़र करने के लिए, खास तौर पर बड़ी फ़ाइलों के लिए ऐसा करना ज़रूरी है. इस तरीके से, आपको सेशन शुरू करने के अनुरोध का इस्तेमाल किया जाता है, जिसमें वैकल्पिक रूप से मेटाडेटा शामिल हो सकता है. यह ज़्यादातर ऐप्लिकेशन के लिए इस्तेमाल की जाने वाली अच्छी रणनीति है, क्योंकि यह हर अपलोड के लिए एक अतिरिक्त एचटीटीपी अनुरोध की लागत पर छोटी फ़ाइलों के लिए भी काम करती है.

मीडिया को अपलोड करते समय, एक खास यूआरआई का इस्तेमाल किया जाता है. असल में, मीडिया अपलोड का समर्थन करने वाले तरीकों में दो यूआरआई एंडपॉइंट होते हैं:

• मीडिया के लिए, /upload यूआरआई. अपलोड एंडपॉइंट का फ़ॉर्मैट एक मानक संसाधन यूआरआई है, जिसमें “/upload” प्रीफ़िक्स है. मीडिया डेटा को ट्रांसफ़र करते समय, इस यूआरआई का इस्तेमाल करें.

  उदाहरण: POST /upload/mirror/v1/timeline

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

  उदाहरण: POST /mirror/v1/timeline

अपलोड करने में आसान

फ़ाइल अपलोड करने का सबसे आसान तरीका है, एक आसान अपलोड अनुरोध करना. यह विकल्प तब एक अच्छा विकल्प होता है, जब:

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

सामान्य अपलोड का इस्तेमाल करने के लिए, तरीके के /upload यूआरआई में POST या PUT का अनुरोध करें और क्वेरी पैरामीटर uploadType=media जोड़ें. उदाहरण के लिए:

POST https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=media

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

• Content-Type एपीआई के रेफ़रंस रेफ़रंस में दिए गए, तरीकों में से किसी एक तरह के अपलोड मीडिया डेटा सेट करें.
• Content-Length. उन बाइट की संख्या सेट करें जो आप अपलोड कर रहे हैं. अगर आप शेयर किए गए ट्रांसफ़र को कोड में बदलने का तरीका इस्तेमाल कर रहे हैं, तो यह ज़रूरी नहीं है.

उदाहरण: आसान अपलोड

इस उदाहरण में, Google मिरर एपीआई को अपलोड करने के आसान अनुरोध का इस्तेमाल करने के बारे में बताया गया है.

POST /upload/mirror/v1/timeline?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/jpeg
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

JPEG data

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

कई हिस्सों में अपलोड करें

अगर आपके पास ऐसा मेटाडेटा है जिसे आप अपलोड करने के लिए डेटा के साथ भेजना चाहते हैं, तो आप सिर्फ़ एक multipart/related अनुरोध कर सकते हैं. अगर आपका डेटा इतना छोटा है कि कनेक्शन नहीं हो पाता है, तो यह एक अच्छा विकल्प है.

मल्टीपार्ट अपलोड का इस्तेमाल करने के लिए, तरीके के /upload यूआरआई में POST या PUT का अनुरोध करें और क्वेरी पैरामीटर uploadType=multipart जोड़ें, जैसे:

POST https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=multipart

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

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

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

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

1. मेटाडेटा पार्ट: पहले आना चाहिए और Content-Type को स्वीकार किए गए मेटाडेटा फ़ॉर्मैट में से किसी एक से मेल खाना चाहिए.
2. मीडिया वाला हिस्सा: दूसरा होना ज़रूरी है. साथ ही, Content-Type, मीडिया के MIME टाइप में से किसी एक से मेल खाना चाहिए.

हर तरीके का मीडिया MIME टाइप और अपलोड की गई फ़ाइलों के साइज़ की सीमा की सूची के लिए, एपीआई रेफ़रंस देखें.

ध्यान दें: सिर्फ़ मेटाडेटा से जुड़ा डेटा बनाने या उसे अपडेट करने के लिए, उससे जुड़े डेटा को अपलोड किए बिना, स्टैंडर्ड रिसॉर्स एंडपॉइंट पर POST या PUT का अनुरोध भेजें: https://www.googleapis.com/mirror/v1/timeline

उदाहरण: कई हिस्सों में अपलोड करें

नीचे दिए गए उदाहरण में, Google मिरर एपीआई के लिए कई हिस्सों में अपलोड करने का अनुरोध दिखाया गया है.

POST /upload/mirror/v1/timeline?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

{
  "text": "Hello world!"
}

--foo_bar_baz
Content-Type: image/jpeg

JPEG data
--foo_bar_baz--

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

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

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

फिर से शुरू किए जा सकने वाले अपलोड का इस्तेमाल करने के तरीके:

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

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

ध्यान दें: अपलोड यूआरआई की समयसीमा एक हफ़्ते की होती है.

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

फिर से शुरू करने लायक अपलोड शुरू करने के लिए, तरीके के /upload यूआरआई में POST या PUT का अनुरोध करें और क्वेरी पैरामीटर uploadType=resumable जोड़ें, जैसे:

POST https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=resumable

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

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

• X-Upload-Content-Type: बाद के अनुरोधों में ट्रांसफ़र किए जाने वाले अपलोड डेटा के मीडिया MIME टाइप पर सेट करें.
• X-Upload-Content-Length. बाद के अनुरोधों में ट्रांसफ़र किए जाने वाले अपलोड डेटा के बाइट की संख्या पर सेट करें. अगर अनुरोध करते समय इसकी लंबाई की जानकारी नहीं है, तो आप इस हेडर को छोड़ सकते हैं.
• अगर मेटाडेटा दिया जा रहा है: Content-Type. मेटाडेटा के डेटा टाइप के हिसाब से सेट करें.
• Content-Length. इस शुरुआती अनुरोध के मुख्य हिस्से में दी गई बाइट की संख्या पर सेट करें. अगर आप शेयर किए गए ट्रांसफ़र को कोड में बदलने का तरीका इस्तेमाल कर रहे हैं, तो यह ज़रूरी नहीं है.

हर तरीके का मीडिया MIME टाइप और अपलोड की गई फ़ाइलों के साइज़ की सीमा की सूची के लिए, एपीआई रेफ़रंस देखें.

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

नीचे दिए गए उदाहरण में, Google Mirror एपीआई के लिए फिर से शुरू करने वाले सेशन को शुरू करने का तरीका बताया गया है.

POST /upload/mirror/v1/timeline?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/jpeg
X-Upload-Content-Length: 2000000

{
  "text": "Hello world!"
}

ध्यान दें: मेटाडेटा के बिना, फिर से शुरू करने से जुड़े शुरुआती अनुरोध के लिए, अनुरोध के मुख्य हिस्से को खाली छोड़ दें. साथ ही, Content-Length हेडर को 0 पर सेट करें.

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

चरण 2: फिर से शुरू करने वाले सत्र यूआरआई को सेव करें

अगर सेशन शुरू होने का अनुरोध पूरा हो जाता है, तो एपीआई सर्वर 200 OK एचटीटीपी स्टेटस कोड के साथ जवाब देता है. साथ ही, यह Location हेडर उपलब्ध कराता है, जो आपके फिर से शुरू किए जाने वाले सेशन यूआरआई के बारे में बताता है. यहां दिए गए उदाहरण में दिखाए गए Location हेडर में, upload_id क्वेरी पैरामीटर वाला हिस्सा शामिल है. इस सेशन में, इस्तेमाल करने के लिए यूनीक अपलोड आईडी दिया गया है.

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

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

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

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

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

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

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

PUT session_uri

फिर से शुरू किए जा सकने वाले फ़ाइल अपलोड के अनुरोध में इस्तेमाल किए जाने वाले एचटीटीपी हेडर में Content-Length शामिल हैं. इसे उन बाइट की संख्या पर सेट करें जिन्हें आप इस अनुरोध में अपलोड कर रहे हैं, जो कि आम तौर पर फ़ाइल का अपलोड आकार होता है.

उदाहरण: फ़ाइल को फिर से अपलोड करने का अनुरोध

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

PUT https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/jpeg

bytes 0-1999999

अनुरोध पूरा होने पर, सर्वर के साथ HTTP 201 Created संसाधन का रिस्पॉन्स देता है. अगर फिर से शुरू किए जा सकने वाले सेशन का शुरुआती अनुरोध PUT था, तो किसी मौजूदा संसाधन को अपडेट करने के लिए, 200 OK का जवाब दिया जाएगा. साथ ही, इस संसाधन से जुड़े सभी मेटाडेटा भी शामिल होंगे.

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

---

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

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

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

अगर डेटा को कई हिस्सों में अपलोड किया जा रहा है, तो Content-Length हेडर के साथ-साथ पूरी फ़ाइल अपलोड करने के लिए भी, Content-Range हेडर की ज़रूरत होती है:

• Content-Length को चमचमाता या कम आकार पर सेट करें, क्योंकि यह आखिरी अनुरोध के मामले में हो सकता है.
• Content-Range: अपलोड करने के लिए फ़ाइल में मौजूद बाइट दिखाने के लिए सेट करें. उदाहरण के लिए, Content-Range: bytes 0-524287/2000000 से पता चलता है कि आपने 2,000,000 बाइट फ़ाइल में, पहले 5,24,288 बाइट (256 x 1024 x 2) आईडी अपलोड किया है.

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

उदाहरण: छोटी की गई फ़ाइल अपलोड करने का अनुरोध

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

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/jpeg
Content-Range: bytes 0-524287/2000000

bytes 0-524288

अगर अनुरोध पूरा हो जाता है, तो सर्वर 308 Resume Incomplete के साथ एक Range हेडर के साथ रिस्पॉन्स देता है, जो अब तक सेव किए गए बाइट की कुल संख्या की पहचान करता है:

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

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

PUT

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

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

फ़ाइल अपलोड होने के बाद, सर्वर HTTP 201 Created के साथ-साथ इस संसाधन से जुड़ा मेटाडेटा अपलोड करता है. अगर यह अनुरोध एक नई इकाई बनाने के बजाय किसी मौजूदा इकाई को अपडेट करता, तो पूरे किए गए अपलोड के लिए एचटीटीपी रिस्पॉन्स कोड 200 OK होता.

---

रुकावट वाले अपलोड को फिर से शुरू करना

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

1. अनुरोध की स्थिति. अपलोड यूआरआई को खाली PUT अनुरोध जारी करके, अपलोड की मौजूदा स्थिति के बारे में क्वेरी करें. इस अनुरोध के लिए, एचटीटीपी हेडर में Content-Range हेडर शामिल होना चाहिए. इससे पता चलता है कि फ़ाइल में मौजूदा जगह के बारे में कोई जानकारी नहीं है. उदाहरण के लिए, अगर आपकी फ़ाइल की कुल लंबाई 2,000,000 है, तो Content-Range को */2000000 पर सेट करें. अगर आपको फ़ाइल का पूरा साइज़ नहीं पता है, तो Content-Range को */* पर सेट करें.

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

2. अपलोड किए गए बाइट की संख्या जानें. स्थिति वाली क्वेरी से मिले जवाब को प्रोसेस करें. यह बताने के लिए कि सर्वर को अब तक कौनसे बाइट मिले हैं, Range हेडर का इस्तेमाल करता है. उदाहरण के लिए, 0-299999 का Range हेडर यह बताता है कि फ़ाइल के शुरुआती 3,00,000 बाइट मिल चुके हैं.
3. बाकी डेटा अपलोड करें. आखिर में, अब जब आपको पता है कि अनुरोध को फिर से शुरू करना है, तो बाकी डेटा या उसका डेटा भेजें. ध्यान दें कि किसी भी मामले में, आपको बाकी डेटा को एक अलग हिस्से के तौर पर रखना होगा, इसलिए अपलोड फिर से शुरू करते समय आपको 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 गड़बड़ियों को ठीक करें.

घातांकीय बैकऑफ़

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

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

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

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

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

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

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

एपीआई क्लाइंट लाइब्रेरी गाइड

• .NET
• Java
• PHP
• Python
• रूबी