मीडिया फ़ाइल अपलोड करें

मीडिया अपलोड करने की सुविधा की मदद से, Display & Cloud में डेटा स्टोर करने और उसे सर्वर पर उपलब्ध कराने के लिए Video 360 API. हम फ़ोटो, वीडियो, PDF फ़ाइलें, ZIP फ़ाइलें या अन्य तरह का डेटा अपलोड कर सकते हैं.

इस दस्तावेज़ में दिए गए उदाहरणों में एक काल्पनिक Farm API के लिए, मीडिया अपलोड करने का तरीका दिखाया गया है. हालांकि यही सिद्धांत Display &Video 360 के ज़रिए Video 360 API.

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

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

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

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

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

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

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

  उदाहरण: POST /upload/farm/v1/animals

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

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

आसान अपलोड

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

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

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

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=media

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

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

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

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

POST /upload/farm/v1/animals?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

{
  "name": "Llama"
}

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

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

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

POST https://www.googleapis.com/upload/farm/v1/animals?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/farm/v1/animals

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

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

POST /upload/farm/v1/animals?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

{
  "name": "Llama"
}

--foo_bar_baz
Content-Type: image/jpeg

JPEG data
--foo_bar_baz--

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

HTTP/1.1 200
Content-Type: application/json

{
  "name": "Llama"
}

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

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

फिर से शुरू किए जाने लायक अपलोड का इस्तेमाल करने के चरणों में ये शामिल हैं:

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

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

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

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

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

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable

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

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

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

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

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

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

POST /upload/farm/v1/animals?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

{
  "name": "Llama"
}

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

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

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

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

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

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

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

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

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

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

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

PUT session_uri

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

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

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

PUT https://www.googleapis.com/upload/farm/v1/animals?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 सर्वर की कोई गड़बड़ी मिलती है, तो एक्सपोनेन्शियल बैकऑफ़ रणनीति का इस्तेमाल करें. ये गड़बड़ियां तब हो सकती हैं, जब सर्वर पर ज़रूरत से ज़्यादा लोड हो. एक्सपोनेन्शियल बैकऑफ़ से अनुरोधों की ज़्यादा संख्या या बहुत ज़्यादा नेटवर्क ट्रैफ़िक के दौरान इस तरह की समस्याओं से बचने में मदद मिल सकती है.
• अन्य तरह के अनुरोधों को एक्स्पोनेंशियल बैकऑफ़ की मदद से हैंडल नहीं किया जाना चाहिए. हालांकि, फिर भी उनमें से कई अनुरोधों को मैनेज करने की कोशिश की जा सकती है. इन अनुरोधों की फिर से कोशिश करते समय, उन्हें फिर से करने की संख्या सीमित करें. उदाहरण के लिए, हो सकता है कि किसी गड़बड़ी की शिकायत करने से पहले आपके कोड को ज़्यादा से ज़्यादा 10 बार या उससे कम बार कोशिश की जाए.
• शुरुआत से पूरा अपलोड फिर से शुरू करके, फिर से शुरू किए जा सकने वाले अपलोड करते समय 404 Not Found और 410 Gone गड़बड़ियों को हल करें.

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

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

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

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

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 सेकंड की देरी हो जाती है. ज़्यादा से ज़्यादा संख्या में कोशिश करने से फ़ायदा हो सकता है. खास तौर पर तब, जब बहुत लंबा वीडियो अपलोड हो रहा हो; कृपया ध्यान रखें कि फिर से कोशिश करने के लिए, एक मिनट से कम का समय दिया गया हो.

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

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