ยอมรับ HTTP 202 (HTTP / 1.1)
คุณกำลังมองหาHTTP 202 Acceptedสถานะ ดูRFC 2616 :
คำขอได้รับการยอมรับสำหรับการประมวลผล แต่การประมวลผลยังไม่เสร็จสมบูรณ์
การประมวลผล HTTP 102 (WebDAV)
RFC 2518แนะนำให้ใช้HTTP 102 Processing:
รหัสสถานะ 102 (กำลังดำเนินการ) เป็นการตอบสนองชั่วคราวที่ใช้เพื่อแจ้งให้ลูกค้าทราบว่าเซิร์ฟเวอร์ยอมรับคำขอที่สมบูรณ์ แต่ยังไม่เสร็จสมบูรณ์
แต่มันมีข้อแม้:
เซิร์ฟเวอร์ต้องส่งคำตอบสุดท้ายหลังจากคำขอเสร็จสมบูรณ์
ฉันไม่แน่ใจว่าจะตีความประโยคสุดท้ายได้อย่างไร เซิร์ฟเวอร์ควรหลีกเลี่ยงการส่งสิ่งใดระหว่างการประมวลผลและตอบกลับหลังจากเสร็จสิ้นเท่านั้น หรือบังคับให้ยุติการตอบสนองก็ต่อเมื่อการประมวลผลสิ้นสุดลงเท่านั้น สิ่งนี้อาจมีประโยชน์หากคุณต้องการรายงานความคืบหน้า ส่ง HTTP 102 และล้างการตอบสนองไบต์โดยไบต์ (หรือทีละบรรทัด)
ตัวอย่างเช่นสำหรับกระบวนการที่มีความยาว แต่เป็นเชิงเส้นคุณสามารถส่งหนึ่งร้อยจุดโดยการล้างหลังจากอักขระแต่ละตัว หากฝั่งไคลเอ็นต์ (เช่นแอปพลิเคชัน JavaScript) รู้ว่าควรคาดหวังว่าจะมี 100 ตัวอักษรแน่นอนมันสามารถจับคู่กับแถบความคืบหน้าเพื่อแสดงต่อผู้ใช้
อีกตัวอย่างหนึ่งเกี่ยวข้องกับกระบวนการซึ่งประกอบด้วยขั้นตอนที่ไม่ใช่เชิงเส้นหลายขั้นตอน หลังจากแต่ละขั้นตอนคุณสามารถล้างข้อความบันทึกที่จะปรากฏต่อผู้ใช้ในที่สุดเพื่อให้ผู้ใช้สามารถทราบว่ากระบวนการทำงานอย่างไร
ปัญหาเกี่ยวกับการล้างข้อมูลแบบโปรเกรสซีฟ
โปรดทราบว่าในขณะที่เทคนิคนี้มีประโยชน์ของมันฉันไม่อยากจะแนะนำ หนึ่งในเหตุผลก็คือมันบังคับให้การเชื่อมต่อยังคงเปิดอยู่ซึ่งอาจเจ็บในแง่ของการให้บริการและไม่ได้ปรับขนาดได้ดี
วิธีที่ดีกว่าคือการตอบสนองHTTP 202 Acceptedและให้ผู้ใช้กลับไปหาคุณในภายหลังเพื่อตรวจสอบว่าการประมวลผลสิ้นสุดลงหรือไม่ (ตัวอย่างเช่นโดยการเรียก URI ที่กำหนดซ้ำ ๆ เช่น/process/resultจะตอบกลับด้วย HTTP 404 ไม่พบหรือHTTP 409 ขัดแย้งจนกว่ากระบวนการ เสร็จสิ้นและผลลัพธ์พร้อมแล้ว) หรือแจ้งผู้ใช้เมื่อดำเนินการเสร็จหากคุณสามารถโทรกลับไปหาลูกค้าผ่านบริการคิวข้อความ ( ตัวอย่าง ) หรือ WebSockets
ตัวอย่างการปฏิบัติ
ลองนึกภาพบริการเว็บที่แปลงวิดีโอ จุดเริ่มต้นคือ:
POST /video/convert
ซึ่งใช้ไฟล์วิดีโอจากคำขอ HTTP และใช้เวทมนตร์กับมัน ลองจินตนาการว่าเวทมนตร์นั้นมีความเข้มข้นของ CPU ดังนั้นจึงไม่สามารถทำได้แบบเรียลไทม์ระหว่างการถ่ายโอนคำขอ ซึ่งหมายความว่าเมื่อไฟล์ถูกถ่ายโอนเซิร์ฟเวอร์จะตอบกลับด้วยHTTP 202 Acceptedเนื้อหา JSON บางส่วนซึ่งหมายถึง“ ใช่ฉันได้รับวิดีโอของคุณแล้วและฉันกำลังทำงานอยู่ มันจะพร้อมบางแห่งในอนาคตและจะสามารถใช้ได้ผ่าน ID 123”
ลูกค้ามีความเป็นไปได้ที่จะสมัครสมาชิกคิวข้อความที่จะได้รับแจ้งเมื่อการประมวลผลเสร็จสิ้น เมื่อเสร็จแล้วลูกค้าสามารถดาวน์โหลดวิดีโอที่ประมวลผลได้โดยไปที่:
GET /video/download/123
HTTP 200ซึ่งนำไปสู่การ
จะเกิดอะไรขึ้นถ้าลูกค้าสอบถาม URI นี้ก่อนที่จะได้รับการแจ้งเตือน เซิร์ฟเวอร์จะตอบกลับด้วยHTTP 404ตั้งแต่จริง ๆ แล้ววิดีโอยังไม่มีอยู่ มันอาจจะเตรียมในปัจจุบัน มันอาจไม่ได้รับการร้องขอ อาจมีอยู่ในอดีตและถูกลบออกในภายหลัง สิ่งที่สำคัญคือวิดีโอที่ได้นั้นไม่สามารถใช้ได้
ทีนี้จะเกิดอะไรขึ้นถ้าลูกค้าไม่เพียง แต่สนใจวิดีโอขั้นสุดท้ายเท่านั้น แต่ยังเกี่ยวกับความคืบหน้า (ซึ่งจะมีความสำคัญมากกว่านี้หากไม่มีบริการคิวข้อความหรือกลไกที่คล้ายกัน)
ในกรณีนี้คุณสามารถใช้ปลายทางอื่น:
GET /video/status/123
ซึ่งจะส่งผลการตอบสนองเช่นนี้:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
การทำคำขอซ้ำแล้วซ้ำอีกจะแสดงความคืบหน้าจนกว่าจะถึง:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
สิ่งสำคัญคือการสร้างความแตกต่างระหว่างคำขอทั้งสามประเภท:
POST /video/convertจัดคิวงาน มันควรจะถูกเรียกเพียงครั้งเดียว: การเรียกมันอีกครั้งจะคิวงานเพิ่มเติมGET /video/download/123เกี่ยวข้องกับผลลัพธ์ของการดำเนินการ: ทรัพยากรคือวิดีโอ การประมวลผล - นั่นคือสิ่งที่เกิดขึ้นภายใต้ประทุนเพื่อเตรียมผลลัพธ์ที่แท้จริงก่อนที่จะมีการร้องขอและเป็นอิสระต่อคำขอ - ไม่เกี่ยวข้องที่นี่ สามารถเรียกได้หนึ่งครั้งหรือหลายครั้งGET /video/status/123เกี่ยวข้องกับการประมวลผลตามลำดับ มันไม่ได้คิวอะไรเลย ไม่สนใจวิดีโอที่เกิดขึ้น ทรัพยากรคือการประมวลผลตัวเอง สามารถเรียกได้หนึ่งครั้งหรือหลายครั้ง