Play Games Services Publishing API की मदद से इमेज अपलोड करना

Play Games Services Publishing API की मदद से, किसी गेम की इमेज अपलोड की जा सकती है संसाधन.

फ़ाइल अपलोड करने के विकल्प

Play Games Services Publishing API का इस्तेमाल करके, कुछ खास तरह के गेम अपलोड किए जा सकते हैं बाइनरी डेटा या मीडिया. अपलोड किए जा सकने वाले डेटा की विशेषताएं मीडिया अपलोड करने के किसी भी तरीके के रेफ़रंस पेज पर इनकी जानकारी दी जाती है:

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

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

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

• सरल अपलोड: 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 यूआरआई और क्वेरी पैरामीटरuploadType=media जोड़ें. उदाहरण के लिए:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media

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

• Content-Type. डेटा को अपलोड करने के लिए, तरीकों के स्वीकार किए गए डेटा टाइप में से किसी एक पर सेट करें. Publishing API में दी गई जानकारी रेफ़रंस.

• 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 का अनुरोध कर सकते हैं. यह एक अच्छा विकल्प है, अगर इतनी छोटी फ़ाइल अपलोड की जा सकती है, अगर कनेक्शन विफल.

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

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart

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

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

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

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

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

• मेटाडेटा वाला हिस्सा: सबसे पहले आना चाहिए. साथ ही, कॉन्टेंट का टाइप, स्वीकार किए गए मेटाडेटा फ़ॉर्मैट में से किसी एक से मैच होना चाहिए.

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

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

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

यहां दिए गए उदाहरण में, Play Games Services Publishing API के लिए, एक से ज़्यादा हिस्सों में डेटा अपलोड करने का अनुरोध दिखाया गया है.

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
}

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

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

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

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

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

3. मीडिया फ़ाइल को फिर से शुरू किए जाने लायक सेशन यूआरआई पर भेजें.

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

फिर से शुरू किया जा सकने वाला सेशन शुरू करें

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

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable

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

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

• X-Upload-Content-Type. बाद के अनुरोधों में ट्रांसफ़र करने के लिए, अपलोड किए गए डेटा के मीडिया एमआईएमई टाइप पर सेट करें.

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

• अगर मेटाडेटा दे रहे हैं, तो: Content-Type. मेटाडेटा के डेटा के हिसाब से सेट करें टाइप करें.

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

Publishing API का रेफ़रंस देखें .

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

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

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
}

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

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

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

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

फ़ाइल अपलोड करें

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

PUT session_uri

फिर से शुरू किए जाने योग्य फ़ाइल अपलोड अनुरोध करते समय उपयोग किए जाने वाले HTTP हेडर में 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 से जुड़े अनुरोध. इससे आपको अपलोड करने जैसे काम भी करने की सुविधा मिलती है लेगसी ब्राउज़र के लिए प्रोग्रेस के संकेत, जिनमें अपलोड की प्रोसेस को पूरा करने की सुविधा नहीं है डिफ़ॉल्ट रूप से.

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

• Content-Length. डेटा को डेटा सेगमेंट पर या उससे कम पर सेट करें. ऐसा पिछले अनुरोध के मामले में भी हो सकता है.

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

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

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

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

bytes 0-524288

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

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 होता.

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

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

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

2. अपलोड की गई बाइट की संख्या पाएं. स्टेटस क्वेरी का जवाब प्रोसेस करें. सर्वर अपने रिस्पॉन्स में Range हेडर का इस्तेमाल करके यह बताता है कि उसके पास कौनसे बाइट हैं अभी तक मिले हैं. उदाहरण के लिए, 0-299999 का Range हेडर दिखाता है कि फ़ाइल की पहली 300,000 बाइट मिल गई हैं.

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

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

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

   PUT {session_uri} HTTP/1.1
   Content-Length: 0
   Content-Range: bytes */2000000
   

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

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42

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

PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999

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

मीडिया अपलोड करते समय, आपको Google से जुड़े सबसे सही तरीकों के बारे में जानना चाहिए गड़बड़ियों को ठीक करने में मदद मिलती है.

• उन फ़ाइलों को दोबारा अपलोड करें या अपलोड करने की कोशिश फिर से करें जो कनेक्शन में होने वाली रुकावटों या 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 response पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
9. आठ सेकंड + रैंडम_number_मिलीसेकंड से इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
10. HTTP 503 response पाएं. इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
11. 16 सेकंड और रैंडम नंबर_मिलीसेकंड से ज़्यादा इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
12. बंद करो। गड़बड़ी की शिकायत करें या लॉग इन करें.

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

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

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

• .नेट

• Java

• PHP

• Python

• रुबी