งานบางอย่างจบใน request เดียวได้ เช่น อ่านรายละเอียดรายการหนึ่ง แต่ถ้าเป็นการส่งออกข้อมูลจำนวนมากหรือประมวลผลไฟล์ การรอเปิด connection ไว้จนทำครบอาจนานกว่าที่หน้าเว็บกับตัวกลางยอมรอได้
ทางเลือกหนึ่งคือรับงานไว้แล้วประมวลผลเบื้องหลัง แต่เมื่อแยกออกมา ผู้ใช้ก็ยังต้องรู้ว่าส่งสำเร็จหรือยัง งานเริ่มหรือยัง และจะกลับมารับผลจากที่ไหน หากมีเพียงข้อความกำลังทำงานโดยไม่มีตัวอ้างอิง คนอาจปิดหน้าแล้วสั่งซ้ำเพราะไม่แน่ใจว่ารอบก่อนยังอยู่หรือหายไปแล้ว
จึงควรออกแบบสัญญาของงานเบื้องหลังพร้อม API ครับ ให้การตอบรับ การตามสถานะ และผลสุดท้ายมีความหมายคนละขั้นแต่เชื่อมกันได้ ไม่ใช้ response เดียวแสดงเหมือนทำสำเร็จครบทั้งที่เพิ่งรับเข้าคิว
HTTP 202 Accepted มีความหมายว่ารับคำขอไว้สำหรับการประมวลผล แต่ยังไม่ได้ยืนยันว่าการประมวลผลเสร็จหรือจะสำเร็จในท้ายที่สุด จึงเหมาะจะพิจารณากับรูปแบบที่ต้องตามผลต่างหากตามการออกแบบ
สิ่งที่ตอบควรมีข้อมูลให้ตามงานได้ เช่น job ID กับ URL หรือข้อมูลสำหรับอ่านสถานะ โดยตรวจว่าระบบบันทึกการรับงานถึงจุดที่รับผิดชอบต่อได้แล้วก่อนตอบ ไม่สร้างรหัสในหน่วยความจำแล้วส่งให้ผู้ใช้ทั้งที่งานอาจหายทันทีเมื่อ process หยุด
ตัวอย่างสมมติอาจรับคำขอส่งออกแล้วคืนสถานะ queued พร้อมรหัสงาน ส่วนวิธีใส่ status URL ใน body หรือ header เป็นข้อตกลง API ที่ต้องระบุให้ชัด ไม่ควรบอกว่า 202 บังคับรูปแบบข้อมูลของ job ให้ครบอยู่ในตัวแล้ว
หากผู้เรียกไม่เห็นคำตอบรอบรับงาน ก็ยังต้องมีวิธีตรวจหรือส่งซ้ำโดยไม่สร้าง job ใหม่ทุกครั้งตามความหมายของงาน เช่น ใช้รหัสการดำเนินการเดิมที่ API รองรับ การมีงานเบื้องหลังไม่ได้แก้ความคลุมเครือของการส่งขาดกลางทางให้เอง
Endpoint สถานะต้องตรวจสิทธิ์ของผู้เรียกกับงานนั้นเหมือนข้อมูลส่วนอื่น ไม่คิดว่าเดารหัสได้ยากแล้วเปิดให้อ่านผลได้โดยไม่ตรวจขอบเขต โดยเฉพาะงานที่สร้างไฟล์จากข้อมูลลูกค้าหรือข้อมูลโครงการ
ควรผูก job กับตัวตนและบริบทที่รับมาจริงตั้งแต่ต้น แล้วใช้ข้อมูลนั้นตอนตรวจสิทธิ์ ไม่ยอมให้ผู้เรียกเปลี่ยนเจ้าของจาก parameter ของหน้าสถานะเพียงอย่างเดียว
ข้อมูลที่แสดงควรพอให้คนจัดการงานได้ เช่น เวลารับ สถานะ ข้อผิดพลาดที่อธิบายได้ และจุดรับผลเมื่อพร้อม ส่วน stack trace, token หรือ path ภายในที่ไม่ช่วยให้ผู้ใช้แก้ ไม่ควรถูกส่งออกมากับทุก error ของ worker
ถ้าผลเป็นไฟล์ที่มีอายุการเข้าถึง ต้องบอกอายุและทางสร้างหรือรับใหม่ตามที่ระบบรองรับ การเห็น job สำเร็จในประวัติไม่ได้รับรองว่า URL ดาวน์โหลดเดิมจะใช้ได้ตลอดไปโดยไม่มีนโยบายเก็บไฟล์
สถานะของ job เองก็ควรมีระยะเก็บที่ชัด หากผู้ใช้กลับมาหลังพ้นช่วงที่ระบบรักษาประวัติไว้ ต้องแยกกรณีหมดอายุของข้อมูลออกจากการไม่พบเพราะรหัสผิดหรือไม่มีสิทธิ์ตามข้อตกลงที่เปิดเผยได้ ไม่เปลี่ยนความหมายย้อนหลังว่างานที่เคยสำเร็จกลายเป็นล้มเหลวเพียงเพราะไฟล์ถูกเก็บกวาดแล้ว
ชุดสถานะอาจเริ่มจาก queued, running, succeeded และ failed ตามที่งานต้องใช้ แต่บางระบบต้องมีสถานะอื่น เช่น รอข้อมูลยืนยัน หรือยกเลิกที่กำลังรอ worker รับคำขอ ไม่ควรบีบทุกเหตุการณ์ให้เป็นสำเร็จหรือล้มเหลวทันทีหากผลยังไม่ชัด
หากรายงาน progress ต้องอิงข้อมูลที่ประเมินได้จริง การนับจำนวนรายการที่ทำแล้วมีความหมายต่างจากร้อยละเวลาที่เหลือ งานที่แต่ละรายการใช้เวลาไม่เท่ากันจึงไม่ควรใช้จำนวนเสร็จมารับรองว่าจะจบในอีกกี่นาทีโดยไม่มีวิธีประมาณรองรับ
เมื่อ worker หยุดกลางทาง สถานะ running ต้องมีวิธีถูกตรวจพบว่าค้างหรือยังมีผู้ทำอยู่ ไม่ปล่อยให้ค้างตลอดเพียงเพราะไม่มี process กลับมาเขียน failed การใช้ lease หรือ heartbeat เป็นทางเลือกเชิงออกแบบที่ต้องกำหนดอายุและวิธีกู้ตามระบบที่เลือก
ผลสุดท้ายก็ควรถูกยืนยันตามสิ่งที่ผู้ใช้ต้องรับจริง เช่น ไฟล์สร้างครบและเข้าถึงได้ในขอบเขตที่อนุญาต ไม่ใช้การจบฟังก์ชัน worker แบบไม่โยน error แทนการตรวจผลทุกส่วนของงาน
หน้าจอสามารถขอสถานะเป็นช่วงๆ ได้ แต่ต้องเลือกช่วงให้เหมาะกับเวลาและจำนวน job ไม่ยิงถี่เท่ากันตลอดเมื่อมีผู้ใช้จำนวนมาก แล้วทำให้ endpoint สถานะกลายเป็นภาระหลักอีกตัวหนึ่ง
หากใช้ callback หรือ webhook ตอนงานจบ ต้องมีการตรวจที่มา การส่งซ้ำ และทางตามเมื่อ callback ไปไม่ถึงด้วย ผู้ใช้จึงควรยังมีจุดอ้างอิงผลตาม job ได้ ไม่ฝากการรับรู้ทุกอย่างไว้กับการแจ้งครั้งเดียวที่ไม่มีทางตรวจกลับ
หน้าจอที่ปิดแล้วเปิดใหม่ควรกลับมาตามงานเดิมได้ตามสิทธิ์ และอธิบายว่าอยู่สถานะใด ไม่บังคับเริ่ม job ใหม่เพราะ state ของ component เดิมหายไป การมีรายการงานหรือจุดเก็บรหัสตามบริบทช่วยให้ประสบการณ์ต่อเนื่องขึ้นได้
ถ้าหน้าจอเลิกรอ ไม่ได้แปลว่าทาง server ยกเลิก job แล้ว ต้องแยกการเลิกดูจากการขอยกเลิกจริงให้ชัด เพื่อไม่ให้คนเข้าใจว่าปิดแท็บแล้วงานจะไม่สร้างผลต่อ
การรับคำขอยกเลิกอาจยังต้องรอ worker ถึงจุดที่ตรวจได้ และสิ่งที่ทำไปแล้วอาจย้อนกลับไม่ได้ทั้งหมด จึงควรบอกสถานะตามความจริง ไม่ตอบ canceled ทันทีทั้งที่งานกำลังส่งผลออกไปยังบริการภายนอกอยู่
ควรกำหนดว่าแต่ละช่วงยกเลิกได้หรือไม่ และหากเกิดผลบางส่วนจะเก็บหรือจัดการอย่างไร ตัวอย่างงานสร้างไฟล์อาจล้างชิ้นงานชั่วคราวตามนโยบาย ส่วนงานที่เปลี่ยนข้อมูลภายนอกต้องมีขอบเขตการชดเชยหรือการตรวจผลที่ชัดกว่านั้น
ใช้ระบบทดสอบจำลอง worker หยุด การตอบรับขาด การเรียกสถานะโดยไม่มีสิทธิ์ และการขอยกเลิกระหว่างทำ แล้วดูว่ารหัสงานเดิมยังตามได้และผลปลายทางไม่ซ้ำตามที่ตั้งใจ การทดสอบควรตรวจสถานะกับผลจริงร่วมกัน ไม่ดูเฉพาะข้อความหน้าจอ
API งานเบื้องหลังควรบอกชัดว่ารับงานแล้ว กำลังทำ หรือยืนยันผลครบแล้ว พร้อมรหัสที่ตามได้ตามสิทธิ์ เมื่อออกแบบการสังเกตสถานะ การส่งซ้ำ และการยกเลิกร่วมกับวงจร worker ผู้ใช้จะกลับมาดูงานเดิมและเลือกทำต่อได้โดยไม่ต้องเดาจาก connection ที่ยังเปิดอยู่หรือข้อความรอเพียงอย่างเดียว