API​ ​Integration​ ​คือ​อะไร​ ​และ​ธุรกิจ​ควร​เตรียม​ข้อมูล​อะไร​ให้​ทีม​พัฒนา​ก่อน​เริ่ม​งาน

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

เริ่มจากเหตุการณ์ที่ต้องเชื่อม

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

ภาพที่ 1: การเชื่อมต่อที่ชัดต้องรู้ทั้งเหตุการณ์ ข้อมูลที่ส่ง และผลที่ระบบปลายทางควรทำ

เช็กลิสต์ก่อนขอประเมินงาน

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

อย่าลืมงานหลังเชื่อมสำเร็จ

ต้องมีคนดูว่ารายการไหนส่งไม่สำเร็จ วิธีลองใหม่โดยไม่สร้างข้อมูลซ้ำ และวิธีแก้เมื่อ API ฝั่งใดฝั่งหนึ่งเปลี่ยน หากไม่มีเจ้าของงานส่วนนี้ การเชื่อมที่สาธิตได้อาจยังใช้ปฏิบัติการประจำวันไม่ได้

คำศัพท์พื้นฐานที่ช่วยคุยกับทีมพัฒนา

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

เอกสาร API ควรบอกเส้นทางเรียก รูปแบบข้อมูล วิธีพิสูจน์สิทธิ์ รหัสข้อผิดพลาด และตัวอย่างที่ทดสอบได้ มาตรฐาน OpenAPI เป็นหนึ่งในวิธีอธิบายข้อตกลงของ HTTP API ให้ทีมต่างระบบอ่านตรงกัน อย่างไรก็ตาม เอกสารที่ดีไม่แทนการตกลงกฎทางธุรกิจ เช่น สถานะ “ยกเลิก” ในแต่ละระบบมีความหมายตรงกันหรือไม่

ตัวอย่างสมมติ: ส่งคำสั่งซื้อเข้าระบบหลังบ้าน

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

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

สิทธิ์และความปลอดภัยของข้อมูล

ให้สิทธิ์ API เท่าที่งานต้องใช้ แยกข้อมูลทดสอบจากข้อมูลจริง และระบุผู้ดูแลกุญแจหรือข้อมูลรับรอง ไม่ควรส่งข้อมูลส่วนบุคคลจริงผ่านเอกสารตัวอย่างหรือ log โดยไม่จำเป็น การตรวจสิทธิ์ต้องพิจารณาระดับรายการด้วย เช่น ผู้ใช้ที่เรียก API ได้ไม่ได้หมายความว่าอ่านคำสั่งซื้อของทุกองค์กรได้ ประเด็นนี้อยู่ในกลุ่มความเสี่ยงที่ OWASP API Security Top 10 เรียกว่า Broken Object Level Authorization

โครงรายงานสำหรับประเมินการเชื่อมต่อ

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

ดู บริการพัฒนาระบบหลังบ้านและ API Integration หรืออ่าน ตัวอย่าง LINE OA เชื่อมระบบหลังบ้าน

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

• OpenAPI Specification 3.1.1 — รูปแบบอธิบายข้อตกลงของ HTTP API
• OWASP API Security Top 10: 2023 — ความเสี่ยงสำคัญของ API รวมถึงสิทธิ์ระดับข้อมูล