5 Guidelines ในการพัฒนา LINE Messaging API ที่แนะนำจาก Dev Docs มีอะไรบ้าง
บทความนี้สั้นๆครับจะมาแนะนำสิ่งที่ควรทำเวลาเราพัฒนา LINE Messaging API ที่มาจาก Official ของ LINE Dev Docs (เน้นให้ LINE DEV มือใหม่ แต่มือเก๋าก็มารีวิวดูได้นะครับ ^^) รวบรวมมาให้ 5 เรื่องจะมีอะไรบ้าง ไปดูกันฮะ!
1. Saving Logs — จัดการเกี่ยวกับการเก็บ Log
เวลาเราพัฒนา LINE Messaging API จะมี 2 ส่วนหลักๆด้วยกันที่เราควรจะทำการเก็บ Log ไว้คือ
- ตอนเราเป็นคนเรียกใช้ API เช่น ส่ง Push, ผูก Rich menu etc.
- ตอนที่เราได้รับ Webhook มาจากผู้ใช้
เพื่อที่เมื่อเกิดปัญหาขึ้นเราจะสามารถตรวจสอบสาเหตุของปัญหาได้นั่นเองครับ
1.1 สิ่งที่ควรเก็บใน Logs สำหรับตอนที่เราเรียกใช้ API
- Request ID (
x-line-request-id) ที่ได้จาก Response headers - วันเวลาของ API request
- Request method
- API endpoint
- Status code ที่ได้จาก LINE Platform
1.2 สิ่งที่ควรเก็บใน Logs สำหรับตอนที่เราได้รับ Webhook จากผู้ใช้
- IP Address ของเครื่องที่ส่ง Webhook มาให้เรา
- เวลาที่ได้รับ Webhook
- Request method
- Request path
- Status code ที่ได้รับมาจาก Response ใน Webhook
ข้อมูลเพิ่มเติมที่อาจจะเป็นประโยชน์ในการเก็บ:
- Request body parameters ที่เราจะเรียกใช้ API
- Response body ที่ได้รับคืนจาก LINE Platform หลังจากเรียกใช้ API
- Signature (
x-line-signature) ของ request headers - Webhook event objects ที่ได้รับคืนมาจาก LINE Platform
2. ถ้าจะส่งข้อความให้แนบค่า X-Line-Retry-Key ด้วย
เวลาที่เราต้องการส่งข้อความ Push/Multicast/Narrowcast/Broadcast อาจจะเกิดข้อผิดพลาดขณะส่ง เราอาจได้รับ Error 500 หรือ Request timeout แต่ใน Dev Docs แจ้งว่าถึงแม้จะได้รับ Error ก็มีโอกาสที่ข้อความของเราจะถูกส่งออกไป (แงง) ดังนั้นหากถ้าเราทำการส่งซ้ำอีกครั้งเนื่องจากเกิดข้อผิดพลาด User อาจได้รับข้อความเดิม 2 ครั้ง (แถมเปลือง Message เราด้วย…)
วิธีที่ Dev Docs แนะนำก็คือให้ทำการแนบ X-Line-Retry-Key ไปในการส่งข้อความ เวลาที่เราแนบค่านี้มา Request ของเราถูกประมวลผลเพียงครั้งเดียว ไม่ว่าเราจะส่ง Request มาอีกกี่ครั้งก็ตาม (เมื่อ Request แรกถูกประมวลผลไปแล้ว Request ที่ถูกส่งมาใหม่จะถูกบล็อก และเราจะได้รับ Status 409 กลับมา
อ่านเรื่องการใช้งาน X-Line-Retry-Key เพิ่มเติมได้ที่นี่ครับผม
3. ไม่ Load Test บน LINE Platform (อย่าทำนู๋เลยย)
เชื่อว่าเพื่อนๆ LINE DEV ที่ทำงานอยู่ในองค์กรใหญ่ๆน่าจะมีกฎในการทำ Load test กับระบบ 3rd party เพื่ออยากดูความสามารถในการรับ Load แต่เว้น LINE Platform ไว้สักอันครับ _/\_ ในการเรียกใช้ API กำหนดจำนวนความถี่ของ Request ให้อยู่ภายใน Rate limit ที่กำหนด ถ้าเกิดส่งมาถี่มากเกินเราจะได้รับ Error 429 Too Many Requests กลับไปครับ
4. ไม่ควบคุมการเข้าถึง Webhook server ด้วย IP Address
เนื่องจาก LINE Platform ไม่สามารถเปิดเผย IP Address ได้ และตัว IP Address ก็อาจมีการเปลี่ยนแปลงได้ตลอดโดยไม่สามารถแจ้งให้ทราบล่วงหน้า ใน DevDocs จะแนะนำว่าแทนที่จะควบคุมการเข้าถึงด้วย IP Addressให้เราใช้การตรวจสอบ Signature (x-line-signature) เพื่อปฏิเสธ Request แปลกๆที่ไม่ได้รับอนุญาต
หมายเหตุ: เราสามารถ Fix IP Address ของฝั่งเราในการเรียก LINE API ได้ (แต่จะใช้ได้กับ Long-lived Channel Access Token เท่านั้น) อ่านบทความเพิ่มเติมได้ที่นี่
5. จัดการ Webhook ที่เข้ามาแบบ Async
ใน Dev Docs แนะนำให้ประมวลผล Webhook event object แบบ Asynchronous เพื่อให้การประมวลผล HTTP POST request ที่กำลังส่งตามเข้ามาไม่เกิดความล่าช้า ซึ่งใน Dev Docs ยังเขียนด้วยว่าในกรณีที่ Webhook Server ที่ไม่สามารถรับ Webhook เป็นเวลานาน (ไม่ตอบกลับ 200 OK) ฝั่ง LINE อาจจะ Suspended การส่ง Webhook ได้ครับ
Note: ใน 1 Webhook อาจจะมี Webhook event objects หลายๆตัวส่งเข้ามา ยกตัวอย่างเช่น นาย A กำลังคุยกับ Chatbot เราอยู่ในขณะเดียวกันนาย B กด Add Chatbot เข้ามา เราก็จะได้ทั้ง Message event ของนาย A และ Follow event ของนาย B มาพร้อมกันใน Webhook ตัวเดียวกัน (แต่คนละ Event objects) ต้องเขียนโค้ดเพื่อ Handle ให้ดีด้วยนะครัช พี่ตี๋เขียนบทความเรื่องนี้ไว้แล้วมาอ่านได้ที่นี่ฮะ
สรุป
เนื้อหาส่วนใหญ่ LINE DEV อาจจะทราบกันอยู่แล้วเนอะ ถ้าใครมี Best Practices อะไรดีย์ๆที่อยากบอกต่อเพื่อช่วยเหลือให้นักพัฒนาท่านอื่นเก่งขึ้นไปด้วย มาแชร์ได้ในกลุ่ม Community LINE Developers Thailand ได้เลยนะครับผม ไปด้วยกัน ไปได้ไกลฮะ!
