Webhook ในเวิร์กโฟลว์วิดีโอ: ทำไปป์ไลน์ของคุณให้ทำงานอัตโนมัติ

แนะนำ Webhook

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

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

ตั้งค่า URL ของ Webhook ที่ไหน

การตั้งค่าเป็นแบบเฉพาะของแต่ละผู้ให้บริการเสมอ คุณลงทะเบียน endpoint HTTPS สาธารณะของคุณในแดชบอร์ดหรือ API ของผู้ให้บริการรายนั้น ๆ ไม่ว่าจะเป็นบริการเข้ารหัสวิดีโอ แพลตฟอร์มไลฟ์ ผู้ให้บริการชำระเงิน และอื่น ๆ ขั้นตอนโดยทั่วไปคือ: วาง URL สำหรับเรียกกลับ เลือกประเภทเหตุการณ์ที่ต้องการรับ และเก็บรักษาความลับสำหรับลงลายเซ็นที่ผู้ให้บริการออกให้ไว้อย่างปลอดภัย ไม่มี "หน้า webhook" สากลที่ใช้ได้กับทุกผู้ให้บริการ คุณต้องทำตามเอกสารของผลิตภัณฑ์ที่คุณเชื่อมต่อจริง ๆ เพราะตำแหน่งและคำศัพท์ที่แน่นอนแตกต่างกันทุกครั้ง

DCAST และผลิตภัณฑ์สำหรับนักพัฒนา

ประสบการณ์สำหรับครีเอเตอร์สาธารณะที่ dcast.tv ไม่มีหน้าตั้งค่า "Webhooks" ทั่วไปที่ให้คุณเพิ่ม URL ใด ๆ สำหรับเหตุการณ์อย่าง "ทรานส์โค้ดเสร็จสิ้น" หรือ "สตรีมเริ่มแล้ว"

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

เหตุการณ์ Webhook ที่พบบ่อยในเวิร์กโฟลว์วิดีโอ

ชื่อเหตุการณ์ที่แน่นอนแตกต่างกันตามผู้ให้บริการ แต่หมวดหมู่ของเหตุการณ์สอดคล้องกันอย่างน่าทึ่งทั่วทั้งอุตสาหกรรม

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

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

ทำความเข้าใจ Payload ของ Webhook

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

{
  "event": "transcoding_finished",
  "video_id": "12345",
  "status": "success",
  "filename": "example_video.mp4",
  "timestamp": "2023-10-05T12:00:00Z"
}

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

จัดการ Webhook ด้วย Node.js

ตั้งค่าตัวรับฟังอย่างง่าย

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;

app.use(bodyParser.json());

app.post('/webhook', (req, res) => {
  const payload = req.body;
  console.log('Received webhook event: ' + payload.event);
  res.status(200).send('Webhook received');
});

app.listen(port, () => {
  console.log('Webhook server listening on port ' + port);
});

ตัวอย่าง: แยกการทำงานตามประเภทเหตุการณ์

app.post('/webhook', (req, res) => {
  const payload = req.body;
  if (payload.event === 'transcoding_finished') {
    console.log('Transcoding finished for video ' + payload.video_id);
  }
  res.status(200).send('Webhook received');
});

การตรวจสอบลายเซ็น

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

const crypto = require('crypto');

function verifySignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(rawBody)
    .digest('hex');
  // constant-time compare avoids leaking timing information
  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signatureHeader)
  );
}

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

การจัดการข้อผิดพลาดและการลองใหม่

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

แนวปฏิบัติที่ดีที่สุด

1. ความปลอดภัย: ใช้ HTTPS เสมอ ตรวจสอบลายเซ็นในทุกคำขอ และปฏิเสธคำขอที่ไม่ผ่านการตรวจสอบด้วย 401 หรือ 403
2. Idempotency: สมมติว่ามีการส่งซ้ำ และกำจัดรายการซ้ำตาม ID ของเหตุการณ์ เพื่อให้การส่งซ้ำไม่ทำให้เก็บเงินซ้ำ เผยแพร่ซ้ำ หรือแจ้งเตือนซ้ำ
3. ตอบรับอย่างรวดเร็ว: ตอบด้วย 2xx ให้เร็ว แล้วค่อยทำงานจริงในคิวเบื้องหลัง
4. การมอนิเตอร์: บันทึกทุกการส่งและความล้มเหลว ตั้งการแจ้งเตือนเมื่อการตอบกลับที่ไม่ใช่ 2xx พุ่งสูง และเก็บ dead-letter queue สำหรับเหตุการณ์ที่ประมวลผลไม่ได้

ทดสอบ Webhook ในเครื่องของคุณ

เนื่องจาก webhook ต้องใช้ URL ที่เข้าถึงได้จากสาธารณะ การทดสอบบนแล็ปท็อปของคุณจึงต้องใช้อุโมงค์ (tunnel) เครื่องมืออย่าง ngrok เปิดเซิร์ฟเวอร์ในเครื่องของคุณผ่านที่อยู่ HTTPS สาธารณะชั่วคราว เพื่อให้ผู้ให้บริการเข้าถึง http://localhost:3000 ได้ระหว่างพัฒนา ผู้ให้บริการหลายรายยังมีปุ่ม "ส่งเหตุการณ์ทดสอบ" และบันทึกการส่งที่แสดงทุกความพยายามพร้อมรหัสตอบกลับที่คุณส่งคืน ใช้ทั้งสองอย่างเพื่อยืนยันว่า endpoint ของคุณตรวจสอบลายเซ็น ตอบ 2xx ได้เร็ว และจัดการ payload ได้ถูกต้องก่อนจะพึ่งพามันบนระบบจริง

บทสรุป

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

ขั้นตอนถัดไปและแหล่งข้อมูล

• ใช้เอกสารอย่างเป็นทางการของผู้ให้บริการเข้ารหัสหรือสตรีมมิ่งของคุณสำหรับประเภทเหตุการณ์ รูปแบบ payload และรายละเอียดการตรวจสอบลายเซ็น
• สำหรับ DCAST ให้พึ่งพาเอกสาร Partner API / นักพัฒนา ที่เผยแพร่แล้วเพื่อทำความเข้าใจขอบเขตการเชื่อมต่อ และอย่าสมมติว่ามี UI สำหรับ webhook ในแดชบอร์ดผู้บริโภคบน dcast.tv