Webhook (خطّاف الويب) آلية إشعار فوري بين التطبيقات: بدل أن تسأل خدمةً باستمرار «هل حدث جديد؟»، تقوم الخدمة نفسها بإرسال بيانات الحدث إلى رابط (URL) تحدّده أنت، لحظة وقوع الحدث. هو حجر أساس الأتمتة الحديثة وربط الخدمات في الزمن الحقيقي.
نقاط أساسية
- دفع (Push) فوري عند الحدث، لا سحب (Pull) متكرّر.
- يرسل طلب HTTP (غالبًا POST) يحمل بيانات الحدث بصيغة JSON.
- يحتاج رابطًا عامًا (endpoint) يستقبل الطلب — مثل عقدة Webhook في n8n.
- يجب تأمينه لأنّه نقطة دخول مفتوحة من الخارج.
Webhook مقابل الاستطلاع (Polling)
الطريقة التقليدية لمعرفة التحديثات هي الاستطلاع (Polling): تسأل الخدمة كل دقيقة مثلًا «هل من جديد؟». هذا مهدر — معظم الطلبات تعود فارغة، ويأتي التحديث متأخّرًا بمقدار فترة السؤال. الـWebhook يقلب المعادلة: الخدمة هي من يبادر بإبلاغك فور الحدث، فتحصل على بيانات لحظية بلا طلبات ضائعة وبحمل أقلّ على الطرفين. لذا يُفضَّل Webhook كلّما كان متاحًا، ويبقى الاستطلاع بديلًا حين لا تدعم الخدمة الإشعار الفوري.
كيف يعمل عمليًّا؟
تبدأ بإنشاء نقطة استقبال (endpoint): رابط عام جاهز لاستقبال الطلبات — في n8n مثلًا تنشئ عقدة Webhook فتعطيك رابطًا فريدًا. تسجّل هذا الرابط في الخدمة المصدر (متجرك، نظام دفع، نموذج)، فحين يقع الحدث (طلب جديد، دفعة ناجحة) ترسل الخدمة طلب HTTP إلى رابطك يحمل تفاصيل الحدث. يستقبل مسارك البيانات ويبدأ التنفيذ فورًا: يعالجها، يصفّيها، ويتّخذ إجراءً. هكذا يصبح كل حدث خارجي مُشغّلًا لحظيًّا لأتمتتك.
تأمين الـWebhook
لأنّ الرابط عامّ ويقبل طلبات من الخارج، يجب حمايته من الإساءة والتزوير. الممارسات الأساسية: استخدم رابطًا يصعب تخمينه (بمعرّف عشوائي طويل)، وتحقّق من توقيع الطلب (secret/signature) إن وفّرته الخدمة المصدر لتثبت أنّه منها فعلًا، واقبل فقط البيانات المتوقّعة، واستخدم HTTPS دائمًا. هذه الطبقات تمنع مهاجمًا من إطلاق أتمتتك بطلبات مزيّفة.
| المفهوم | الدور |
|---|---|
| Endpoint | الرابط الذي يستقبل الإشعار |
| Payload | بيانات الحدث (غالبًا JSON) |
| Signature/Secret | إثبات أنّ الطلب من المصدر الموثوق |
| Push مقابل Pull | إشعار فوري بدل سؤال متكرّر |