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

เกี่ยวกับการอัปโหลดสื่อ

Google Mirror API ช่วยให้คุณแทรกไฟล์แนบเมื่อสร้างรายการไทม์ไลน์ใหม่ได้

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

Google Mirror API ช่วยให้คุณอัปโหลดข้อมูลไบนารีหรือสื่อบางประเภทได้ ลักษณะเฉพาะของข้อมูลที่คุณสามารถอัปโหลดได้ในหน้าอ้างอิงสําหรับวิธีการใดๆ ที่รองรับการอัปโหลดสื่อ ดังนี้

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

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

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

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

URI สําหรับ /upload สําหรับสื่อ รูปแบบของปลายทางการอัปโหลดคือ URI ทรัพยากรมาตรฐานที่มีคํานําหน้า "/upload" ใช้ URI นี้เมื่อโอนข้อมูลสื่อเอง
เช่น POST /upload/mirror/v1/timeline
URI ทรัพยากรมาตรฐานสําหรับข้อมูลเมตา หากทรัพยากรมีช่องข้อมูล ระบบจะใช้ช่องเหล่านั้นเพื่อจัดเก็บข้อมูลเมตาที่อธิบายไฟล์ที่อัปโหลด คุณจะใช้ URI นี้เมื่อสร้างหรืออัปเดตค่าข้อมูลเมตาได้
ตัวอย่าง POST /mirror/v1/timeline

อัปโหลดได้ง่าย

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

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

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

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

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

Content-Type ตั้งค่าเป็นประเภทข้อมูลสื่อในการอัปโหลดที่ยอมรับวิธีหนึ่ง ตามที่ระบุไว้ในข้อมูลอ้างอิงของ API
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

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

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

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

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

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

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

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

เนื้อหาของคําขอมีรูปแบบเป็นเนื้อหาประเภท multipart/related [RFC2387] และมี 2 ส่วนพอดี ส่วนต่างๆ จะระบุด้วยสตริงขอบเขต และสตริงขอบเขตสุดท้ายตามด้วยเครื่องหมายขีดกลาง 2 ขีด

แต่ละส่วนของคําขอที่มีข้อมูลหลายส่วนต้องมีส่วนหัว Content-Type เพิ่มเติม:

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

โปรดดูข้อมูลอ้างอิง API สําหรับรายการแต่ละประเภท 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--

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

การอัปโหลดที่กลับมาทํางานอีกครั้ง

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

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

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

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

หมายเหตุ: URI การอัปโหลดจะหมดอายุหลังจากผ่านไป 1 สัปดาห์

ขั้นตอนที่ 1: เริ่มเซสชันกลับมาทํางานอีกครั้ง

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

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

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

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

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

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

ตัวอย่างต่อไปนี้แสดงวิธีเริ่มเซสชันกลับมาทํางานอีกครั้งสําหรับ 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

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

ขั้นตอนที่ 2: บันทึก URI เซสชันที่กลับมาทํางานอีกครั้ง

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

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

คําตอบสําหรับคําขอในขั้นตอนที่ 1 มีดังนี้

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

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

คัดลอกและบันทึก URI ของเซสชันเพื่อให้ใช้กับคําขอที่ตามมาได้

ขั้นตอนที่ 3: อัปโหลด

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

PUT session_uri

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

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

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

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 ระบุว่าคุณให้ขนาด 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 เมื่อคุณอัปโหลดต่อ

ตัวอย่าง: การอัปโหลดที่กลับมาทํางานอีกครั้ง

1) ขอสถานะการอัปโหลด

คําขอต่อไปนี้ใช้ส่วนหัว Content-Range เพื่อระบุว่าไม่ทราบตําแหน่งปัจจุบันในไฟล์ 2,000,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
ใช้กลยุทธ์ Exponential Backoff หากเกิดข้อผิดพลาดเกี่ยวกับเซิร์ฟเวอร์ 5xx เมื่อกลับมาขอหรือดําเนินการอัปโหลดอีกครั้ง ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นหากเซิร์ฟเวอร์ทํางานหนักเกินไป Exponential Backoff สามารถช่วยลดปัญหาประเภทนี้ในช่วงที่มีคําขอจํานวนมากหรือมีการเข้าชมเครือข่ายสูง
ส่วนคําขอประเภทอื่นๆ ไม่ควรได้รับการจัดการโดย Exponential Backoff แต่คุณยังคงลองอีกครั้งได้จํานวนหนึ่ง เมื่อลองส่งคําขอเหล่านี้อีกครั้ง ให้จํากัดจํานวนครั้งที่จะลองใหม่ ตัวอย่างเช่น รหัสอาจจํากัดการทดสอบไม่เกิน 10 ครั้งก่อนที่จะรายงานข้อผิดพลาด
แก้ไขข้อผิดพลาด 404 Not Found และ 410 Gone เมื่ออัปโหลดต่อที่เริ่มต้นโดยเริ่มทั้งการอัปโหลดตั้งแต่ต้น

Exponential Backoff

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

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

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

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

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

หมายเหตุ: การรอคือ (2 ^ n) +แบบสุ่ม_number_milliseconds เสมอ โดย n เป็นจํานวนเต็มที่เพิ่มขึ้นแบบโมโนนิกซึ่งกําหนดเป็น 0 จํานวนเต็ม n จะเพิ่มขึ้นอีก 1 ค่าสําหรับการทําซ้ําแต่ละรายการ (คําขอแต่ละรายการ)

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