API​ ​Integration​ ​ควร​ออกแบบ​ ​Error​ ​Handling​ ​และ​ ​Retry​ ​อย่างไร

การเชื่อม API ใช้งานจริงไม่ได้วัดจากทางสำเร็จอย่างเดียว ต้องตอบว่าเมื่อปลายทางไม่ตอบ ตอบช้า หรือส่งผลกลับไม่ครบจะเกิดอะไรขึ้น Error Handling คือการจำแนกผลและเลือกการกระทำ ส่วน Retry คือการลองใหม่เฉพาะกรณีที่ปลอดภัยและมีโอกาสสำเร็จ

แยกข้อผิดพลาดก่อนลองใหม่

ข้อมูลไม่ผ่านกฎหรือไม่มีสิทธิ์มักต้องแก้ข้อมูล/สิทธิ์ ไม่ควรลองซ้ำไม่สิ้นสุด ส่วนเครือข่ายขาดหรือบริการไม่พร้อมชั่วคราวอาจลองใหม่ได้ แต่ต้องจำกัดจำนวนครั้งและเว้นระยะเพิ่มขึ้น (backoff) หากได้รับ 429 Too Many Requests ให้ดูคำแนะนำการรอ เช่น Retry-After เมื่อผู้ให้บริการส่งมา แล้วลดอัตราเรียกตามข้อจำกัดของบริการ

ภาพที่ 1: การลองใหม่ต้องขึ้นกับชนิดข้อผิดพลาดและความปลอดภัยของการทำซ้ำ

ตัวอย่างสมมติ: สร้างคำสั่งซื้อปลายทาง

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

หลัง Retry หมดควรเกิดอะไร

เก็บสถานะรายการ เหตุผล เวลา จำนวนครั้งที่ลอง และช่องทางให้คนตรวจหรือสั่งลองใหม่อย่างปลอดภัย แจ้งเตือนเมื่อรายการค้างเกินเกณฑ์ที่ทีมกำหนด แยกผล “ส่งคำขอแล้ว” จาก “ปลายทางยืนยันแล้ว” ในหน้าจอและรายงาน ไม่ทำให้ผู้ใช้เข้าใจว่างานสำเร็จทั้งที่ยังไม่ทราบผล

สำหรับรายงาน

ทำตารางประเภท Error การกระทำ จำนวนครั้งและช่วงรอสูงสุด วิธีป้องกันข้อมูลซ้ำ และเจ้าของงานเมื่อแก้เองไม่ได้ ระบุสมมติฐานเกี่ยวกับความสามารถของ API ภายนอกให้ชัด และทดสอบ Timeout กับผลตอบกลับที่กำกวม ไม่ทดสอบแต่ HTTP 200

อ่าน Webhook vs API และ Rate Limit หรือดู บริการระบบหลังบ้านและ API

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ตารางรหัสผิดพลาด เงื่อนไข retry, backoff และ idempotency key ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• Google Cloud: Retry strategy — การลองใหม่ตามชนิดข้อผิดพลาดและ backoff
• Stripe: Idempotent requests — ตัวอย่างสัญญา Idempotency ของผู้ให้บริการ
• RFC 6585: 429 Too Many Requests — ความหมายของ 429 และ Retry-After