Webhook​ ​คือ​อะไร​ ​และ​แตก​ต่าง​จาก​ ​REST​ ​API​ ​อย่างไร

Webhook คือวิธีที่ระบบต้นทางส่ง HTTP Request ไปยัง URL ที่ลงทะเบียนเมื่อเกิดเหตุการณ์ เช่น มีคำสั่งซื้อใหม่ ส่วนการเรียก REST API มักเป็นระบบปลายทางเป็นฝ่ายขอข้อมูลหรือสั่งงานเมื่อจำเป็น ความต่างหลักคือใครเป็นฝ่ายเริ่มการสื่อสารและเมื่อใด ไม่ใช่ว่า Webhook “ไม่ใช้ API” เพราะ Webhook เองก็ใช้ HTTP และต้องมีสัญญาข้อมูล

ตัวอย่างสมมติ: ออเดอร์ใหม่

ระบบขายอาจให้หลังบ้านเรียก GET /orders ทุกช่วงเวลาเพื่อหาออเดอร์ใหม่ หรือส่ง Webhook มาทันทีเมื่อออเดอร์เกิด หากต้องการข้อมูลรายละเอียดเพิ่มเติม Webhook อาจส่งเพียงรหัสออเดอร์ แล้วหลังบ้านเรียก API ไปอ่านรายละเอียดอีกครั้ง จึงใช้สองวิธีร่วมกันได้

ภาพที่ 1: API แบบเรียกเมื่อจำเป็นและ Webhook แบบส่งเมื่อเกิดเหตุการณ์ตอบจังหวะงานต่างกัน

สิ่งที่ต้องออกแบบเพิ่มสำหรับ Webhook

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

เลือกวิธีใด

ถ้าต้องรู้การเปลี่ยนเกือบทันทีและผู้ให้บริการรองรับ Webhook อาจเหมาะ หากต้องดึงข้อมูลย้อนหลังหรือซ่อมรายการที่พลาด API แบบดึงยังสำคัญ ตรวจเอกสารผู้ให้บริการเรื่องการลองส่งใหม่ อัตราเรียก และอายุข้อมูล เพราะเงื่อนไขต่างกัน ไม่ใช้คำว่า “Real-time” หากยังไม่พิสูจน์เวลาส่งจริง

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

วาดผู้เริ่ม Request ชนิดเหตุการณ์ ข้อมูลที่ส่ง จุดตรวจความถูกต้อง และกรณีปลายทางล่ม เทียบข้อดีข้อจำกัดของ Pull กับ Push ตามโจทย์งาน ระบุว่าผู้ให้บริการใดรองรับอะไรจริง

อ่าน API Integration Preparation และ LINE OA Workflow หรือดู บริการระบบหลังบ้านและ API

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

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

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

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

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

• LINE Developers: Receive messages with webhooks — ตัวอย่างการส่งเหตุการณ์ ตรวจลายเซ็น และรับการส่งซ้ำ
• MDN: REST — แนวคิดบริการบน Resource