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

Google Mirror API, आपको नया टाइमलाइन आइटम बनाते समय अटैचमेंट शामिल करने देता है.

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

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

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

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

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

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

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

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

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

  उदाहरणः POST /mirror/v1/timeline अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

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

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

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

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

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

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. इसे multipart/related पर सेट करें और अनुरोध के हिस्सों की पहचान करने के लिए, वह बॉर्डर स्ट्रिंग शामिल करें जिसका इस्तेमाल किया जा रहा है.
• Content-Length. अनुरोध के मुख्य हिस्से में बाइट की कुल संख्या पर सेट करें. अनुरोध का मीडिया हिस्सा, इस तरीके के लिए तय किए गए फ़ाइल के ज़्यादा से ज़्यादा साइज़ से कम होना चाहिए.

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

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

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

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

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

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

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

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 API के लिए फिर से शुरू किए जा सकने वाले सेशन को शुरू करने का तरीका बताया गया है.

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 पर सेट करें.

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

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

अगर सेशन शुरू करने का अनुरोध पूरा हो जाता है, तो एपीआई सर्वर एक 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

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

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

यहां मौजूदा उदाहरण के लिए, 2,000,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-Range हेडर के साथ-साथ Content-Length हेडर की भी ज़रूरत होगी, जो पूरी फ़ाइल अपलोड करने के लिए ज़रूरी है:

• Content-Length. डेटा को डेटा सेगमेंट पर या उससे कम पर सेट करें. ऐसा पिछले अनुरोध के मामले में भी हो सकता है.
• Content-Range: यह दिखाने के लिए सेट करें कि आपकी अपलोड की जा रही फ़ाइल में कौन-कौनसी बाइट अपलोड की जा रही हैं. उदाहरण के लिए, Content-Range: bytes 0-524287/2000000 दिखाता है कि आप 20,00,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 अनुरोध में रुकावट आती है या आपको सर्वर से एचटीटीपी 503 Service Unavailable या कोई अन्य 5xx रिस्पॉन्स मिलता है, तो रुकी हुई अपलोड की प्रोसेस फिर से शुरू करें में बताए गए तरीके का पालन करें. हालांकि, बाकी फ़ाइल को अपलोड करने के बजाय, उस बिंदु से चंक अपलोड करना जारी रखें.

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

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

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

---

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

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

1. अनुरोध की स्थिति. अपलोड के यूआरआई पर खाली PUT अनुरोध भेजकर, अपलोड की मौजूदा स्थिति के बारे में क्वेरी करें. इस अनुरोध के लिए, एचटीटीपी हेडर में Content-Range हेडर शामिल होना चाहिए. इससे पता चलता है कि फ़ाइल की मौजूदा पोज़िशन की जानकारी नहीं है. उदाहरण के लिए, अगर आपकी फ़ाइल की कुल लंबाई 20,00,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 सर्वर की कोई गड़बड़ी मिलती है, तो एक्सपोनेन्शियल बैकऑफ़ रणनीति का इस्तेमाल करें. अगर सर्वर पर ज़्यादा लोड आ रहा है, तो ये गड़बड़ियां हो सकती हैं. एक्सपोनेन्शियल बैकऑफ़ से अनुरोधों की ज़्यादा संख्या या बहुत ज़्यादा नेटवर्क ट्रैफ़िक के दौरान इस तरह की समस्याओं से बचने में मदद मिल सकती है.
• अन्य तरह के अनुरोधों को एक्स्पोनेंशियल बैकऑफ़ की मदद से हैंडल नहीं किया जाना चाहिए. हालांकि, फिर भी उनमें से कई अनुरोधों को मैनेज करने की कोशिश की जा सकती है. इन अनुरोधों की फिर से कोशिश करते समय, उन्हें फिर से करने की संख्या सीमित करें. उदाहरण के लिए, किसी गड़बड़ी की रिपोर्ट करने से पहले आपके कोड को दस या उससे कम बार कोशिश की जा सकती है.
• फिर से शुरू किए जा सकने वाले अपलोड करते समय, 404 Not Found और 410 Gone गड़बड़ियों को ठीक करने के लिए, पूरा अपलोड फिर से शुरू करें.

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

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

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

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

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

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

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

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

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

• .NET
• Java
• PHP
• Python
• Ruby