Webhook คืออะไร ต่างจาก API ยังไง พร้อมลองส่งเข้า Discord

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

โปรแกรมคอมพิวเตอร์ก็เจอเรื่องเดียวกันทุกวัน วิธีแรกเรียกว่า Polling ส่วนวิธีที่สองคือสิ่งที่คุณเห็นในคำค้นอย่าง "webhook discord คือ" หรือ "webhook url คือ" วันนี้ Superdev Academy จะพาไปดูว่า Webhook คืออะไร ต่างจากการเรียก API ตรงไหน ลองส่งข้อความเข้า Discord ด้วยคำสั่งเดียว แล้วปิดท้ายด้วยสามเรื่องที่มือใหม่มักพลาดเมื่อต้องรับ Webhook เอง

Polling กับ Webhook ถามซ้ำๆ หรือรอให้อีกฝั่งบอก

Polling (การถามซ้ำเป็นรอบ) คือการให้โปรแกรมของคุณเรียก API ของอีกระบบซ้ำๆ ตามเวลาที่ตั้งไว้ เช่น ทุก 1 นาที ถามว่ามีออเดอร์ใหม่ไหม มีคนเปิด Issue ใหม่ไหม คำตอบส่วนใหญ่คือ "ยังไม่มี" แต่ทุกคำถามก็กินแรงทั้งสองฝั่ง และถ้าเหตุการณ์เกิดขึ้นหลังรอบที่แล้วแค่ไม่กี่วินาที คุณก็ต้องรออีกเกือบเต็มรอบกว่าจะรู้

Webhook กลับทิศกัน คุณเอา URL ของคุณไปลงทะเบียนไว้กับอีกระบบหนึ่งครั้ง จากนั้นเมื่อเกิดเหตุการณ์ที่คุณสนใจ ระบบนั้นจะส่ง HTTP Request มาที่ URL ของคุณเอง พร้อมข้อมูลของเหตุการณ์นั้น คุณไม่ต้องถามอะไรเลย

• Polling: คุณถามซ้ำๆ ว่ามีอะไรใหม่ไหม

• Webhook: อีกระบบยิงมาที่ URL ของคุณเมื่อมีเหตุการณ์

GitHub เขียนไว้ในเอกสารของตัวเองว่า Webhook ใช้แรงและทรัพยากรน้อยกว่าการ Poll API และได้ข้อมูลเกือบเรียลไทม์ เพราะมันถูกส่งออกมาตอนที่เหตุการณ์เกิดขึ้นพอดี

Webhook ต่างจาก API ยังไง

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

ตอนที่คุณเรียก API คุณเป็นฝั่งเริ่มคุย ส่ง Request ไปถาม แล้วรอ Response กลับมา (ถ้ายังไม่คุ้นกับภาพนี้ อ่าน API คืออะไร ทำงานอย่างไร ก่อนได้) ส่วน Webhook คุณกลายเป็นฝั่งที่รอรับ อีกระบบเป็นคนเริ่มคุย ทั้งสองแบบใช้ HTTP เหมือนกัน ต่างกันแค่ว่าใครเป็นคนกดส่งก่อน

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

Webhook ทำงานยังไง: มันคือ HTTP Request หนึ่งครั้ง

ไม่มีเวทมนตร์อะไรซ่อนอยู่ ตัวอย่างจาก GitHub คือ เมื่อมีเหตุการณ์ที่คุณเลือกไว้ GitHub จะส่ง POST มาที่ URL ของคุณ เนื้อหาเป็น JSON (หรือ form-urlencoded ถ้าเลือกแบบนั้น) และแนบ Header ที่บอกบริบทมาด้วย เช่น

• X-GitHub-Event: เหตุการณ์นี้คืออะไร เช่น push หรือ issues

• X-GitHub-Delivery: รหัสไม่ซ้ำของการส่งครั้งนี้

• X-Hub-Signature-256: ลายเซ็นที่ใช้พิสูจน์ว่า GitHub เป็นคนส่งจริง (จะกลับมาพูดถึงข้างล่าง)

GitHub ยังระบุด้วยว่า Payload ใหญ่สุดได้ 25 MB ถ้าเหตุการณ์ไหนใหญ่กว่านั้นจะไม่ถูกส่งเลย

ส่วนคำว่า "Webhook คือ HTTP POST" ถูกเกือบทุกกรณี แต่ไม่ใช่กฎตายตัว เช่น Webhook node ของ n8n รับได้ทั้ง GET, POST, PUT, PATCH, DELETE และ HEAD ถ้าอยากทบทวนว่า Request กับ Response ประกอบด้วยอะไรบ้าง เรามีบทความ การทำงานกับ HTTP Requests และ Responses ให้อ่านต่อ

ลองเล่น: ส่งข้อความเข้า Discord ด้วย curl คำสั่งเดียว

ตัวอย่างที่จับต้องได้ง่ายที่สุดคือ Incoming Webhook ของ Discord ซึ่งรอบนี้คุณจะเป็นฝั่งส่ง และ Discord เป็นฝั่งรับ

ขั้นแรก สร้าง Webhook ในเซิร์ฟเวอร์ Discord ที่คุณเป็นแอดมิน ตามคู่มือของ Discord คือเข้า Server Settings แล้วไปที่แท็บ Integrations กด Create Webhook เลือก channel ที่จะให้ข้อความไปโผล่ แล้วกด Copy Webhook URL จะได้ URL หน้าตาประมาณ https://discord.com/api/webhooks/<id>/<token>

ขั้นที่สอง เปิด Terminal แล้วส่งข้อความด้วย curl (ถ้ายังไม่คล่อง Terminal ดู คำสั่ง Terminal ที่ควรรู้ ประกอบได้)

curl -X POST "https://discord.com/api/webhooks/<id>/<token>" \
  -H "Content-Type: application/json" \
  -d '{"content": "Deploy เสร็จแล้ว"}'

สิ่งที่ เอกสาร Execute Webhook ของ Discord ระบุไว้ และควรรู้ก่อนลองมีดังนี้

• ต้องมีอย่างน้อยหนึ่งใน content, embeds, components, file หรือ poll

• content ยาวได้ไม่เกิน 2000 ตัวอักษร

• ถ้าไม่ใส่ ?wait=true ท้าย URL ค่าเริ่มต้นคือไม่รอ และ Discord จะตอบกลับเป็น 204 No Content คือสำเร็จแต่ไม่มีเนื้อหาตอบกลับ

• ใส่ username หรือ avatar_url เพื่อเปลี่ยนชื่อและรูปของผู้ส่งเฉพาะข้อความนั้นได้

ทีมเราลองยิงคำสั่งเดียวกันไปที่ URL ที่แต่ง id และ token ขึ้นมาเอง ได้ 404 กลับมาพร้อม {"message": "Unknown Webhook", "code": 10015} ถ้าคุณเจอข้อความนี้ แปลว่า URL ผิดหรือ Webhook ถูกลบไปแล้ว

อีกเรื่องที่ควรรู้คือ Webhook ของ Discord ทำหน้าที่โพสต์ข้อความเข้า channel อย่างเดียว ถ้าอยากได้ระบบที่อ่านข้อความแล้วตอบกลับใน Discord ได้ ต้องไปทางบอต ซึ่งเราเล่าไว้ใน ปั้นทีม AI Multi-Agent บน Discord

ฝั่งรับ: เมื่อ GitHub หรือ LINE ยิงมาหาคุณ

พอสลับมาเป็นฝั่งรับ งานของคุณคือเปิด URL หนึ่งตัวบนเซิร์ฟเวอร์ให้พร้อมรับ Request แล้วเอา URL นั้นไปกรอกในระบบต้นทาง

GitHub: เข้า Settings ของ repository ไปที่ Webhooks กด Add webhook แล้วกรอก Payload URL เลือกเหตุการณ์ที่อยากรับ และตั้ง Secret ไว้ใช้ตรวจลายเซ็น เกร็ดเล็กๆ จากคู่มือของ Discord คือ ถ้าอยากให้ commit ใน GitHub ไปโผล่ใน Discord ให้เอา Webhook URL ของ Discord มาเติม /github ต่อท้าย แล้วใส่เป็น Payload URL ได้เลย

LINE: เอกสาร Messaging API ของ LINE อธิบายว่า เมื่อผู้ใช้ทักบัญชี LINE OA ของคุณ LINE Platform จะส่ง HTTP POST พร้อม webhook event object ไปที่ Webhook URL ที่คุณลงทะเบียนไว้ URL นั้นต้องเป็น HTTPS และทุก Request มี Header x-line-signature ที่คุณต้องตรวจก่อนประมวลผล

ถ้าคุณเคยเห็นบทเรียนเก่าที่สอนส่งแจ้งเตือนเข้า LINE ด้วย LINE Notify ตอนนี้ใช้ไม่ได้แล้ว LINE ประกาศว่าบริการ LINE Notify ยุติไปเมื่อ 31 มีนาคม 2025 และแนะนำให้ย้ายไปใช้ Messaging API แทน

Webhook URL คือความลับ ใครได้ไปก็ส่งได้

สังเกตไหมว่าคำสั่ง curl ข้างบนไม่มี API Key ไม่มีรหัสผ่าน เอกสารของ Discord ระบุตรงๆ ว่า Webhook ไม่ต้องใช้ bot user และไม่ต้องยืนยันตัวตน เพราะ token ฝังอยู่ใน URL แล้ว แปลว่าใครก็ตามที่ได้ URL นี้ไป สามารถโพสต์อะไรก็ได้เข้า channel ของคุณในนามของ Webhook ตัวนั้น

ดังนั้นให้ปฏิบัติกับ Webhook URL เหมือน API Key ทุกประการ เก็บไว้ในไฟล์ .env อย่าเขียนลงโค้ดตรงๆ อย่า commit ขึ้น GitHub และอย่าแปะในแชตกลุ่ม วิธีเก็บให้ปลอดภัยเราอธิบายไว้ใน API Key คืออะไร เก็บในไฟล์ .env ยังไงไม่ให้หลุด ถ้าเผลอหลุดไปแล้ว ให้ลบ Webhook ตัวนั้นใน Discord แล้วสร้างใหม่ URL เก่าจะใช้ไม่ได้ทันที

ตรวจลายเซ็นก่อนเชื่อ: X-Hub-Signature-256

ฝั่งรับมีปัญหากลับด้าน URL ที่คุณเปิดรอไว้เป็น URL สาธารณะ ใครก็ส่ง POST ปลอมมาหลอกว่าเป็น GitHub ได้ ทางแก้คือการตรวจลายเซ็น

เอกสารของ GitHub อธิบายว่า เมื่อคุณตั้ง Secret ไว้ GitHub จะเอา body ของ Request ไปคำนวณ HMAC ด้วย SHA-256 โดยใช้ Secret เป็นกุญแจ แล้วส่งผลลัพธ์มาใน Header X-Hub-Signature-256 ซึ่งขึ้นต้นด้วย sha256= เสมอ ฝั่งคุณแค่คำนวณแบบเดียวกันแล้วเทียบ ถ้าไม่ตรงก็ปฏิเสธไป

const crypto = require('crypto');

function isFromGitHub(rawBody, signature, secret) {
  const expected = 'sha256=' +
    crypto.createHmac('sha256', secret).update(rawBody).digest('hex');
  return signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

ทีมเราลองรันฟังก์ชันนี้บนเครื่องด้วย Node.js แล้วยิง curl ใส่ ลายเซ็นมั่วได้ 401 ส่วนลายเซ็นที่คำนวณถูกได้ 204 จุดที่ต้องระวังคือ GitHub แนะนำให้เทียบด้วยฟังก์ชันแบบ constant time อย่าง crypto.timingSafeEqual แทน === ธรรมดา เพื่อกันการโจมตีแบบจับเวลา และ Header X-Hub-Signature ตัวเก่าที่ใช้ SHA-1 มีไว้เพื่อความเข้ากันได้ย้อนหลังเท่านั้น ส่วน LINE ใช้หลักเดียวกัน คือ HMAC-SHA256 ด้วย channel secret แต่เข้ารหัสผลลัพธ์เป็น Base64 และส่งมาใน x-line-signature

ตอบให้ไว แล้วเตรียมรับของซ้ำ

GitHub กำหนดว่าเซิร์ฟเวอร์ของคุณควรตอบ 2XX ภายใน 10 วินาที ถ้าช้ากว่านั้น GitHub จะตัดการเชื่อมต่อและนับว่าการส่งครั้งนั้นล้มเหลว LINE ก็แนะนำไปทางเดียวกันว่าให้ประมวลผล event แบบ asynchronous (ทำเบื้องหลัง) ภาษาง่ายๆ คือ รับของ ตรวจลายเซ็น ตอบ 200 ไปก่อน แล้วค่อยทำงานหนักทีหลัง

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

เพราะฉะนั้นโค้ดฝั่งรับควรจำรหัสของ event ที่ประมวลผลไปแล้ว เจอซ้ำก็ข้าม GitHub ให้ใช้ X-GitHub-Delivery ซึ่งการ redeliver จะใช้ค่าเดิม ส่วน LINE ให้ใช้ webhookEventId และดู deliveryContext.isRedelivery ประกอบ

Webhook ดีกว่า Polling เสมอไหม

ไม่เสมอ และควรพูดตรงๆ Polling ยังเหมาะเมื่อระบบต้นทางไม่มี Webhook ให้ใช้ เมื่อคุณต้องการข้อมูลแค่นานๆ ครั้ง หรือเมื่อโปรแกรมของคุณรันอยู่บนเครื่องที่ไม่มี URL สาธารณะให้ใครยิงเข้ามาได้

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

สรุป: Webhook ต่างจาก API ยังไง

Webhook คือ HTTP Request ที่อีกระบบส่งมาหาคุณเองเมื่อมีเหตุการณ์ ส่วนการเรียก API คือคุณเป็นฝั่งไปถามเอง ทั้งคู่ใช้ HTTP และมักส่ง JSON เหมือนกัน ต่างกันแค่ทิศทาง ในฝั่งส่ง Webhook URL คือความลับที่ต้องเก็บเหมือน API Key ในฝั่งรับ ให้ตรวจลายเซ็นก่อนเชื่อ ตอบ 2XX ให้ไว และเตรียมรับ event ซ้ำเสมอ

ถ้าอยากเห็นภาพชัดที่สุด ลองสร้าง Webhook ในเซิร์ฟเวอร์ Discord ส่วนตัวของคุณ แล้วส่งข้อความแรกด้วย curl ข้างบนดู พอเห็นข้อความโผล่ใน channel ครั้งแรก คำว่า Webhook จะไม่ใช่ศัพท์ลอยๆ อีกต่อไป

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev Academy Thailand — https://www.facebook.com/superdev.academy.th

YouTube: Superdev Academy Channel — https://www.youtube.com/@SuperdevAcademy

Instagram: @superdevacademy — https://www.instagram.com/superdevacademy/

TikTok: @superdevacademy — https://www.tiktok.com/@superdevacademy?lang=th-TH