หน้านี้ได้รับการแปลโดย Cloud Translation API

อัปโหลดรูปภาพด้วย API การเผยแพร่บริการเกมของ Play

Publishing API สำหรับบริการเกมของ Play ให้คุณอัปโหลดรูปภาพสำหรับแหล่งข้อมูลเกมได้

ตัวเลือกการอัปโหลด

Play Games Services Publishing API ให้คุณอัปโหลดข้อมูลไบนารีหรือสื่อบางประเภทได้ ลักษณะเฉพาะของข้อมูลที่อัปโหลดได้จะระบุไว้ในหน้าข้อมูลอ้างอิงสำหรับวิธีการที่รองรับการอัปโหลดสื่อ

ขนาดไฟล์อัปโหลดสูงสุด: ปริมาณข้อมูลสูงสุดที่คุณจัดเก็บได้ด้วยวิธีนี้
ประเภท MIME ของสื่อที่ยอมรับ: ประเภทข้อมูลไบนารีที่คุณจัดเก็บได้โดยใช้วิธีนี้

คุณส่งคำขอให้อัปโหลดได้โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้ ระบุเมธอดที่ใช้กับพารามิเตอร์คำขอ uploadType

การอัปโหลดแบบง่าย: uploadType=media สำหรับการโอนไฟล์ขนาดเล็กอย่างรวดเร็ว เช่น 5 MB หรือน้อยกว่า
การอัปโหลดแบบหลายส่วน: uploadType=multipart สำหรับการโอนไฟล์และข้อมูลเมตาขนาดเล็กอย่างรวดเร็ว โดยระบบจะโอนไฟล์พร้อมกับข้อมูลเมตาที่อธิบายไฟล์นั้นในคำขอเดียว
การอัปโหลดที่กลับมาดำเนินการต่อได้: uploadType=resumable สำหรับการโอนที่เชื่อถือได้ ซึ่งสำคัญอย่างยิ่งสำหรับไฟล์ขนาดใหญ่ วิธีนี้ใช้คําขอเริ่มต้นเซสชัน ซึ่งจะรวมข้อมูลเมตาหรือไม่ก็ได้ นี่เป็นกลยุทธ์ที่ดีสำหรับการใช้งานส่วนใหญ่ เนื่องจากใช้ได้กับไฟล์ขนาดเล็กด้วย แต่จะต้องเสียค่าใช้จ่ายเพิ่ม 1 คำขอ HTTP ต่อการอัปโหลด

เมื่ออัปโหลดสื่อ คุณจะใช้ URI พิเศษ อันที่จริงแล้ว วิธีต่างๆ ที่รองรับการอัปโหลดสื่อจะมีปลายทาง URI 2 รายการ ดังนี้

URI /upload สำหรับสื่อ รูปแบบของปลายทางการอัปโหลดคือ URI ของทรัพยากรมาตรฐานที่มีคำนำหน้า "/upload" ใช้ URI นี้เมื่อโอนข้อมูลสื่อ

ตัวอย่าง: POST /upload/games/v1configuration/images/resourceId/imageType/imageType
URI ของทรัพยากรมาตรฐานสำหรับข้อมูลเมตา หากทรัพยากรมีฟิลด์ข้อมูล ระบบจะใช้ฟิลด์เหล่านั้นเพื่อจัดเก็บข้อมูลเมตาที่อธิบายไฟล์ที่อัปโหลด คุณสามารถใช้ URI นี้เมื่อสร้างหรืออัปเดตค่าข้อมูลเมตา

ตัวอย่าง: POST /games/v1configuration/images/resourceId/imageType/imageType

การอัปโหลดแบบง่าย

วิธีที่ง่ายที่สุดในการอัปโหลดไฟล์คือการส่งคำขออัปโหลด ตัวเลือกนี้เหมาะสําหรับกรณีที่เป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้

ไฟล์มีขนาดเล็กพอที่จะอัปโหลดอีกครั้งได้ทั้งหมดหากการเชื่อมต่อไม่สำเร็จ
ไม่มีข้อมูลเมตาที่จะส่ง กรณีนี้อาจเกิดขึ้นหากคุณวางแผนที่จะส่งข้อมูลเมตาสำหรับทรัพยากรนี้ในคำขอแยกต่างหาก หรือหากระบบไม่รองรับหรือไม่มีข้อมูลเมตา หากต้องการใช้การอัปโหลดแบบง่าย ให้ส่งคำขอ POST หรือ PUT ไปยัง URI /upload ของเมธอด แล้วเพิ่มพารามิเตอร์การค้นหา uploadType=media เช่น

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

ส่วนหัว HTTP ที่จะใช้ในการส่งคำขออัปโหลดแบบง่ายมีดังนี้

Content-Type. ตั้งค่าเป็นประเภทข้อมูลสื่อการอัปโหลดที่ยอมรับของวิธีการ ซึ่งระบุไว้ในข้อมูลอ้างอิงของ Publishing API
Content-Length. ตั้งค่าเป็นจำนวนไบต์ที่คุณอัปโหลด ไม่จําเป็นหากใช้การเข้ารหัสการโอนแบบแบ่งกลุ่ม

ตัวอย่าง: การอัปโหลดแบบง่าย

ตัวอย่างต่อไปนี้แสดงการใช้คำขออัปโหลดแบบง่ายสำหรับ Play Games Services Publishing API

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

หากคำขอสำเร็จ เซิร์ฟเวอร์จะแสดงรหัสสถานะ HTTP 200 OK พร้อมกับข้อมูลเมตา เช่น

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

การอัปโหลดหลายส่วน

หากมีข้อมูลเมตาที่ต้องการส่งไปพร้อมกับข้อมูลที่อัปโหลด คุณจะส่งคำขอ multipart/related รายการเดียวได้ ตัวเลือกนี้เป็นตัวเลือกที่ดีหากข้อมูลที่คุณส่งมีขนาดเล็กพอที่จะอัปโหลดอีกครั้งทั้งหมดได้หากการเชื่อมต่อล้มเหลว

หากต้องการใช้การอัปโหลดแบบหลายส่วน ให้ส่งคำขอ POST หรือ PUT ไปยัง URI /upload ของเมธอด แล้วเพิ่มพารามิเตอร์การค้นหา uploadType=multipart เช่น

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

ส่วนหัว HTTP ระดับบนสุดที่จะใช้เมื่อส่งคำขอการอัปโหลดแบบหลายส่วนมีดังนี้

-Content-Type. ตั้งค่าเป็น multipart/related และใส่สตริงขอบเขตที่คุณใช้เพื่อระบุส่วนต่างๆ ของคำขอ

-Content-Length. ตั้งค่าเป็นจำนวนไบต์ทั้งหมดในเนื้อหาคำขอ ส่วนสื่อของคําขอต้องน้อยกว่าขนาดไฟล์สูงสุดที่ระบุสําหรับวิธีการนี้

เนื้อหาของคำขออยู่ในรูปแบบประเภทเนื้อหาแบบหลายส่วน/ที่เกี่ยวข้อง RFC2387 และประกอบด้วย 2 ส่วนเท่านั้น ส่วนต่างๆ จะระบุด้วยสตริงขอบเขต และสตริงขอบเขตสุดท้ายจะตามด้วยขีดกลาง 2 ตัว

แต่ละส่วนของคำขอแบบหลายส่วนต้องมีส่วนหัว Content-Type เพิ่มเติม ดังนี้

ส่วนข้อมูลเมตา: ต้องอยู่ก่อนสุด และ Content-Type ต้องตรงกับรูปแบบข้อมูลเมตาที่ยอมรับรูปแบบใดรูปแบบหนึ่ง
ส่วนสื่อ: ต้องอยู่ลำดับที่ 2 และ Content-Type ต้องตรงกับประเภท MIME ของสื่อที่วิธีการยอมรับ

ดูข้อมูลอ้างอิงเกี่ยวกับ Publishing API เพื่อดูรายการประเภท MIME ของสื่อที่ยอมรับและขีดจำกัดขนาดของไฟล์ที่อัปโหลดสำหรับแต่ละเมธอด

ตัวอย่าง: การอัปโหลดแบบหลายส่วน

ตัวอย่างด้านล่างแสดงคำขอการอัปโหลดแบบหลายส่วนสำหรับ Publishing API ของบริการเกมของ Play

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--

หากคำขอสำเร็จ เซิร์ฟเวอร์จะแสดงรหัสสถานะ HTTP 200 OK พร้อมกับข้อมูลเมตา

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

การอัปโหลดที่ดำเนินการต่อได้

คุณสามารถใช้โปรโตคอลการอัปโหลดที่อัปโหลดต่อได้เพื่ออัปโหลดไฟล์ข้อมูลอย่างน่าเชื่อถือยิ่งขึ้น โปรโตคอลนี้ช่วยให้คุณดำเนินการอัปโหลดต่อได้หลังจากการสื่อสารไม่สำเร็จทำให้การไหลของข้อมูลหยุดชะงัก ซึ่งจะมีประโยชน์อย่างยิ่งในกรณีที่คุณกำลังโอนไฟล์ขนาดใหญ่และมีแนวโน้มที่เครือข่ายจะหยุดชะงักหรือการส่งข้อมูลอื่นๆ ล้มเหลว เช่น เมื่ออัปโหลดจากแอปไคลเอ็นต์บนอุปกรณ์เคลื่อนที่ นอกจากนี้ ยังช่วยลดการใช้แบนด์วิดท์ในกรณีที่เครือข่ายทำงานไม่ถูกต้องเนื่องจากคุณไม่จําเป็นต้องเริ่มการอัปโหลดไฟล์ขนาดใหญ่อีกครั้งตั้งแต่ต้น

ขั้นตอนในการใช้การอัปโหลดที่อัปโหลดต่อได้มีดังนี้

เริ่มเซสชันที่กลับมาทำงานต่อได้ ส่งคำขอเริ่มต้นไปยัง URI การอัปโหลดที่มีข้อมูลเมตา (หากมี)
บันทึก URI ของเซสชันที่กลับมาดำเนินการต่อได้ บันทึก URI ของเซสชันที่แสดงผลในการตอบกลับของคำขอแรก คุณจะใช้ URI นี้กับคำขอที่เหลือในเซสชันนี้ อัปโหลดไฟล์
ส่งไฟล์สื่อไปยัง URI ของเซสชันที่กลับมาดำเนินการต่อได้

นอกจากนี้ แอปที่ใช้การอัปโหลดที่อัปโหลดต่อได้ต้องมีโค้ดเพื่ออัปโหลดต่อได้หากการอัปโหลดถูกขัดจังหวะ หากการอัปโหลดถูกขัดจังหวะ ให้ดูปริมาณข้อมูลที่รับได้สําเร็จ แล้วอัปโหลดต่อจากจุดนั้น

เริ่มเซสชันที่กลับมาดำเนินการต่อได้

หากต้องการเริ่มการอัปโหลดที่กลับมาดำเนินการต่อได้ ให้ส่งคำขอ POST หรือ PUT ไปยัง URI /upload ของเมธอด แล้วเพิ่มพารามิเตอร์การค้นหา uploadType=resumable เช่น

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

สำหรับคำขอเริ่มต้นนี้ เนื้อความจะว่างเปล่าหรือมีเฉพาะข้อมูลเมตาเท่านั้น คุณจะโอนเนื้อหาจริงของไฟล์ที่ต้องการอัปโหลดในคำขอต่อๆ ไป

ใช้ส่วนหัว HTTP ต่อไปนี้กับคำขอเริ่มต้น

X-Upload-Content-Type. ตั้งค่าเป็นประเภท MIME ของสื่อของข้อมูลที่อัปโหลดที่จะโอนในคำขอต่อๆ ไป
X-Upload-Content-Length. ตั้งค่าเป็นจำนวนไบต์ของข้อมูลที่อัปโหลดที่จะโอนในคำขอต่อๆ ไป หากไม่ทราบความยาว ณ เวลาที่ส่งคำขอนี้ คุณก็ละส่วนหัวนี้ไปได้
หากระบุข้อมูลเมตา: Content-Type ตั้งค่าตามประเภทข้อมูลของข้อมูลเมตา
Content-Length. ตั้งค่าเป็นจํานวนไบต์ที่ระบุในส่วนเนื้อหาของคําขอเริ่มต้นนี้ ไม่จําเป็นหากใช้การเข้ารหัสการโอนแบบแบ่งกลุ่ม

ดูข้อมูลอ้างอิงของ Publishing API เพื่อดูรายการประเภท MIME ของสื่อที่ยอมรับและขีดจํากัดขนาดของไฟล์ที่อัปโหลดสำหรับแต่ละเมธอด

ตัวอย่าง: คำขอเริ่มต้นเซสชันที่กลับมาทำงานต่อได้

ตัวอย่างต่อไปนี้แสดงวิธีเริ่มเซสชันที่กลับมาทำงานต่อได้สําหรับ Publishing API ของบริการเกมของ Play

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
}

ส่วนถัดไปจะอธิบายวิธีจัดการการตอบกลับ

บันทึก URI ของเซสชันที่กลับมาทำงานต่อได้

หากคำขอเริ่มต้นเซสชันสำเร็จ เซิร์ฟเวอร์ API จะตอบกลับด้วยรหัสสถานะ HTTP 200 OK นอกจากนี้ ยังมีส่วนหัว Location ที่ระบุ URI ของเซสชันที่กลับมาทำงานต่อได้ ส่วนหัว Location ที่แสดงในตัวอย่างด้านล่างมีพารามิเตอร์การค้นหา upload_id ซึ่งระบุรหัสการอัปโหลดที่ไม่ซ้ำกันสำหรับใช้กับเซสชันนี้

ตัวอย่าง: การตอบกลับการเริ่มต้นเซสชันที่กลับมาทำงานต่อได้

นี่คือคำตอบสำหรับคำขอในขั้นตอนที่ 1

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 ตามที่แสดงในตัวอย่างการตอบกลับด้านบนคือ URI เซสชันที่คุณจะใช้เป็นปลายทาง HTTP สำหรับการอัปโหลดไฟล์จริงหรือค้นหาสถานะการอัปโหลด

คัดลอกและบันทึก URI เซสชันเพื่อให้ใช้กับคำขอต่อๆ ไปได้

อัปโหลดไฟล์

หากต้องการอัปโหลดไฟล์ ให้ส่งคำขอ PUT ไปยัง URI การอัปโหลดที่คุณได้รับในขั้นตอนก่อนหน้า รูปแบบของคำขออัปโหลดมีดังนี้

PUT session_uri

ส่วนหัว HTTP ที่จะใช้ในการส่งคำขออัปโหลดไฟล์แบบดำเนินการต่อได้ ได้แก่ Content-Length ตั้งค่านี้เป็นจำนวนไบต์ที่คุณอัปโหลดในคำขอนี้ ซึ่งโดยทั่วไปคือขนาดไฟล์ที่อัปโหลด

ตัวอย่าง: คำขออัปโหลดไฟล์ที่กลับมาดำเนินการต่อได้

นี่คือคำขอที่กลับมาดำเนินการต่อได้เพื่ออัปโหลดไฟล์ PNG ขนาด 2,000,000 ไบต์ทั้งหมดสำหรับตัวอย่างปัจจุบัน

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-Range ด้วย รวมถึงส่วนหัว Content-Length ที่จําเป็นสําหรับการอัปโหลดไฟล์ทั้งไฟล์

Content-Length. ตั้งค่าเป็นขนาดของกลุ่มหรืออาจน้อยกว่าก็ได้ ตามที่อาจเป็นกรณีของคำขอล่าสุด
Content-Range ตั้งค่าเพื่อแสดงไบต์ในไฟล์ที่คุณอัปโหลด ตัวอย่างเช่น Content-Range: bytes 0-524287/2000000 แสดงว่าคุณกำลังส่งไบต์ 524,288 ไบต์แรก (256 x 1024 x 2) ในไฟล์ 2,000,000 ไบต์

ขยายเพื่อดูข้อมูลเพิ่มเติม

หากอัปโหลดข้อมูลเป็นกลุ่ม คุณต้องใช้ส่วนหัว Content-Range ด้วย นอกเหนือจากส่วนหัว Content-Length ที่จําเป็นสําหรับการอัปโหลดไฟล์ทั้งไฟล์

Content-Length. ตั้งค่าเป็นขนาดของกลุ่มหรืออาจน้อยกว่าก็ได้ ตามที่อาจเป็นกรณีของคำขอล่าสุด
Content-Range: ตั้งค่าเพื่อแสดงไบต์ในไฟล์ที่คุณอัปโหลด เช่น Content-Range: bytes 0-524287/2000000 แสดงว่าคุณให้ไบต์ 524,288 ไบต์แรก (256 x 1024 x 2) ในไฟล์ 2,000,000 ไบต์

ข้อจำกัดด้านขนาดของข้อมูล: ข้อมูลทั้งหมดต้องมีขนาดเป็นจำนวนที่คูณด้วย 256 KB (256 x 1024 ไบต์) ยกเว้นข้อมูลสุดท้ายที่อัปโหลดเสร็จสมบูรณ์ หากใช้การแบ่งกลุ่ม คุณต้องทำให้ขนาดกลุ่มมีขนาดใหญ่ที่สุดเท่าที่จะเป็นไปได้เพื่อให้การอัปโหลดมีประสิทธิภาพ

ตัวอย่าง: คำขออัปโหลดไฟล์แบบแบ่งเป็นชิ้นที่กลับมาดำเนินการต่อได้

คำขอที่ส่งไบต์ 524,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 ของข้อมูลโค้ดใดถูกขัดจังหวะ หรือหากคุณได้รับการตอบกลับ HTTP 503 Service Unavailable หรือ 5xx อื่นๆ จากเซิร์ฟเวอร์ ให้ทำตามขั้นตอนที่ระบุไว้ในอัปโหลดต่อจากช่วงที่ขัดจังหวะ แต่แทนที่จะอัปโหลดไฟล์ที่เหลือ ให้อัปโหลดข้อมูลโค้ดต่อจากจุดนั้น

หมายเหตุสำคัญ:

อย่าลืมใช้ส่วนหัว Range ในการตอบกลับเพื่อระบุตำแหน่งเริ่มต้นของข้อมูลโค้ดส่วนถัดไป อย่าคิดว่าเซิร์ฟเวอร์ได้รับไบต์ทั้งหมดที่ส่งในคำขอก่อนหน้า
URI การอัปโหลดแต่ละรายการมีอายุการใช้งานที่จำกัดและจะหมดอายุในที่สุด (ภายใน 1 วันโดยประมาณ หากไม่ได้ใช้งาน) ด้วยเหตุนี้ เราขอแนะนำให้เริ่มการอัปโหลดแบบกลับมาดำเนินการต่อได้ทันทีที่ได้รับ URI การอัปโหลด และกลับมาดำเนินการต่อกับการอัปโหลดที่ถูกขัดจังหวะไม่นานหลังจากที่เกิดปัญหา
หากคุณส่งคำขอที่มีรหัสเซสชันการอัปโหลดที่หมดอายุแล้ว เซิร์ฟเวอร์จะแสดงรหัสสถานะ 404 Not Found เมื่อเกิดข้อผิดพลาดที่กู้คืนไม่ได้ในเซสชันการอัปโหลด เซิร์ฟเวอร์จะแสดงรหัสสถานะ 410 Gone ในกรณีเหล่านี้ คุณต้องเริ่มการอัปโหลดแบบอัปโหลดต่อได้ใหม่ รับ URI การอัปโหลดใหม่ และเริ่มการอัปโหลดตั้งแต่ต้นโดยใช้ปลายทางใหม่

เมื่ออัปโหลดไฟล์ทั้งหมดเสร็จแล้ว เซิร์ฟเวอร์จะตอบกลับด้วย HTTP 201 Created พร้อมกับข้อมูลเมตาที่เชื่อมโยงกับทรัพยากรนี้ หากคำขอนี้อัปเดตเอนทิตีที่มีอยู่แทนการสร้างเอนทิตีใหม่ โค้ดการตอบกลับ HTTP สำหรับการอัปโหลดที่เสร็จสมบูรณ์จะเป็น 200 OK

อัปโหลดต่อ

หากคำขออัปโหลดสิ้นสุดลงก่อนที่จะได้รับการตอบกลับ หรือหากคุณได้รับการตอบกลับ HTTP 503 Service Unavailable จากเซิร์ฟเวอร์ คุณจะต้องอัปโหลดที่หยุดชะงักต่อ หากต้องการอัปโหลดที่หยุดชะงักต่อ ให้ทำดังนี้

สถานะคำขอ ค้นหาสถานะปัจจุบันของการอัปโหลดโดยส่งคำขอ PUT ว่างไปยัง URI การอัปโหลด สําหรับคําขอนี้ ส่วนหัว HTTP ควรมีส่วนหัว Content-Range ที่ระบุว่าไม่ทราบตําแหน่งปัจจุบันในไฟล์ เช่น ตั้งค่า Content-Range เป็น */2000000 หากความยาวไฟล์ทั้งหมดคือ 2,000,000 หากคุณไม่ทราบขนาดเต็มของไฟล์ ให้ตั้งค่า Content-Range เป็น */*

หมายเหตุ: คุณสามารถขอสถานะระหว่างข้อมูลแต่ละส่วนได้ ไม่ใช่เฉพาะในกรณีที่การอัปโหลดถูกขัดจังหวะ ซึ่งจะมีประโยชน์ เช่น หากต้องการแสดงการบ่งชี้ความคืบหน้าการอัปโหลดสำหรับเบราว์เซอร์เวอร์ชันเก่า
รับจำนวนไบต์ที่อัปโหลด ประมวลผลการตอบกลับจากการค้นหาสถานะ เซิร์ฟเวอร์ใช้ส่วนหัว Range ในการตอบกลับเพื่อระบุไบต์ที่ได้รับจนถึงตอนนี้ ตัวอย่างเช่น ส่วนหัว Range ของ 0-299999 บ่งบอกว่าได้รับไบต์แรกของไฟล์ 300,000 ไบต์แล้ว
อัปโหลดข้อมูลที่เหลือ สุดท้าย เมื่อคุณทราบตําแหน่งที่จะส่งคําขอต่อแล้ว ให้ส่งข้อมูลที่เหลือหรือข้อมูลส่วนที่เป็นปัจจุบัน โปรดทราบว่าคุณต้องถือว่าข้อมูลที่เหลือเป็นกลุ่มแยกต่างหากไม่ว่าในกรณีใดก็ตาม คุณจึงต้องส่งส่วนหัว Content-Range เมื่ออัปโหลดต่อ

ตัวอย่าง: อัปโหลดที่หยุดชะงักต่อ

ขอสถานะการอัปโหลด คำขอต่อไปนี้ใช้ส่วนหัว Content-Range เพื่อระบุว่าตำแหน่งปัจจุบันในไฟล์ขนาด 2,000,000 ไบต์นั้นไม่รู้จัก
```
PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000
```
ดึงข้อมูลจำนวนไบต์ที่อัปโหลดจนถึงตอนนี้จากคำตอบ การตอบกลับของเซิร์ฟเวอร์ใช้ส่วนหัว Range เพื่อระบุว่าได้รับไฟล์ 43 ไบต์แรกแล้ว ใช้ค่าบนสุดของส่วนหัว Range เพื่อกำหนดจุดเริ่มต้นการอัปโหลดที่กลับมาทำงานอีกครั้ง
```
HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42
```
หมายเหตุ: การตอบกลับสถานะอาจเป็น201สร้างแล้วหรือ 200 OKหากการอัปโหลดเสร็จสมบูรณ์ กรณีนี้อาจเกิดขึ้นหากการเชื่อมต่อขาดตอนหลังจากอัปโหลดไบต์ทั้งหมดแล้ว แต่ก่อนที่ไคลเอ็นต์จะได้รับการตอบกลับจากเซิร์ฟเวอร์
อัปโหลดต่อจากจุดที่ถูกขัดจังหวะ คำขอต่อไปนี้จะอัปโหลดต่อโดยส่งไบต์ที่เหลือของไฟล์โดยเริ่มจากไบต์ 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
ใช้กลยุทธ์Exponential Backoff หากระบบแสดงข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ 5xx เมื่อกลับมาดำเนินการต่อหรือลองส่งคำขออัปโหลดอีกครั้ง ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นหากเซิร์ฟเวอร์ทำงานหนักเกินไป การลดจำนวนคำขอแบบทวีคูณจะช่วยบรรเทาปัญหาเหล่านี้ได้ในช่วงที่มีคำขอจำนวนมากหรือการจราจรของข้อมูลในเครือข่ายสูง
คำขอประเภทอื่นๆ ไม่ควรจัดการด้วย Exponential Backoff แต่คุณยังคงลองส่งคำขอเหล่านั้นได้ เมื่อลองส่งคําขอเหล่านี้อีกครั้ง ให้จํากัดจํานวนครั้งที่จะลองใหม่ เช่น โค้ดอาจจำกัดการลองใหม่ไว้ที่ 10 ครั้งหรือน้อยกว่าก่อนที่จะรายงานข้อผิดพลาด
จัดการข้อผิดพลาด 404 Not Found และ 410 Gone เมื่อทำการอัปโหลดแบบเริ่มใหม่ได้โดยการเริ่มการอัปโหลดทั้งหมดอีกครั้งตั้งแต่ต้น

Exponential Backoff

Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสําหรับแอปพลิเคชันเครือข่ายที่ไคลเอ็นต์จะส่งคําขอที่ล้มเหลวอีกครั้งเป็นระยะๆ เมื่อเวลาผ่านไป หากคำขอจำนวนมากหรือการจราจรในเครือข่ายที่หนาแน่นทําให้เซิร์ฟเวอร์แสดงข้อผิดพลาด Exponential Backoff อาจเป็นกลยุทธ์ที่ดีในการจัดการข้อผิดพลาดเหล่านั้น ในทางกลับกัน กลยุทธ์นี้ไม่เกี่ยวข้องกับการจัดการข้อผิดพลาดที่ไม่เกี่ยวข้องกับปริมาณเครือข่ายหรือเวลาในการตอบสนอง เช่น ข้อมูลเข้าสู่ระบบการให้สิทธิ์ที่ไม่ถูกต้องหรือข้อผิดพลาดที่ระบุว่าไม่พบไฟล์

เมื่อใช้อย่างเหมาะสม Exponential Backoff จะเพิ่มประสิทธิภาพการใช้แบนด์วิดท์ ลดจํานวนคําขอที่จําเป็นต่อการตอบกลับที่ประสบความสําเร็จ และเพิ่มปริมาณข้อมูลสูงสุดของคําขอในสภาพแวดล้อมแบบพร้อมกัน

ขั้นตอนในการใช้ Exponential Backoff แบบง่ายมีดังนี้

ส่งคําขอไปยัง API
ได้รับคําตอบ HTTP 503 ซึ่งหมายความว่าคุณควรลองส่งคําขออีกครั้ง
รอ 1 วินาที + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
ได้รับคําตอบ HTTP 503 ซึ่งหมายความว่าคุณควรลองส่งคําขออีกครั้ง
รอ 2 วินาที + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
ได้รับคําตอบ HTTP 503 ซึ่งหมายความว่าคุณควรลองส่งคําขออีกครั้ง
รอ 4 วินาที + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
ได้รับ HTTP 503 response ซึ่งหมายความว่าคุณควรลองส่งคำขออีกครั้ง
รอ 8 วินาที + random_number_milliseconds แล้วลองส่งคำขออีกครั้ง
ได้รับ HTTP 503 response ซึ่งหมายความว่าคุณควรลองส่งคำขออีกครั้ง
รอ 16 วินาที + random_number_milliseconds แล้วลองส่งคําขออีกครั้ง
หยุด รายงานหรือบันทึกข้อผิดพลาด

ในรายการข้างต้น random_number_milliseconds คือจำนวนมิลลิวินาทีแบบสุ่มที่น้อยกว่าหรือเท่ากับ 1, 000 ซึ่งจำเป็นต้องทำเนื่องจากความล่าช้าแบบสุ่มเล็กๆ น้อยๆ จะช่วยกระจายภาระงานอย่างสม่ำเสมอยิ่งขึ้นและหลีกเลี่ยงความเป็นไปได้ที่เซิร์ฟเวอร์จะทำงานหนักเกินไป ค่าของ random_number_milliseconds ต้องได้รับการกําหนดใหม่หลังจากการรอแต่ละครั้ง

อัลกอริทึมได้รับการตั้งค่าให้สิ้นสุดเมื่อ n เป็น 5 ขีดจํากัดนี้ป้องกันไม่ให้ไคลเอ็นต์พยายามใหม่อย่างไม่สิ้นสุด และส่งผลให้เกิดความล่าช้าทั้งหมดประมาณ 32 วินาทีก่อนที่จะถือว่าคําขอเป็น "ข้อผิดพลาดที่แก้ไขไม่ได้" จำนวนครั้งที่พยายามสูงสุดที่มากขึ้นนั้นไม่เป็นปัญหา โดยเฉพาะในกรณีที่กำลังอัปโหลดเป็นเวลานาน เพียงแต่ให้กำหนดเวลารอระหว่างการพยายามใหม่ให้เหมาะสม เช่น น้อยกว่า 1 นาที