Webhooks: استقبال الإشعارات الفورية

أهلاً بك في الدرس الثالث. في الدرس الماضي، تعلمنا كيف يمكن لتطبيقاتنا أن "تسأل" الأنظمة الأخرى عن معلومات جديدة باستخدام الـ API، في دورة تسمى الطلب-والاستجابة. كان تطبيقنا هو الذي يبادر دائمًا بالسؤال.

ولكن، تخيل أنك تراقب وصول طلب جديد على متجرك. الطريقة التي تعلمناها تشبه قيامك بتحديث صفحة الطلبات في YouCan كل دقيقة لتتأكد من عدم وجود طلب جديد. هذا الأسلوب، الذي يسمى الاستقصاء (Polling)، غير فعال ويستهلك الموارد. أليس من الأفضل أن يرسل لك نظام YouCan إشعارًا فوريًا في اللحظة التي يتم فيها إنشاء طلب جديد؟

هذا هو بالضبط ما سنتعلمه اليوم. سنكتشف تقنية مكملة للـ API تسمى الـ Webhooks، والتي تسمح للأنظمة بإرسال تحديثات فورية عند وقوع أحداث معينة.

بحلول نهاية هذا الدرس، ستكون قادرًا على فهم مفهوم Webhooks وكيفية استخدامها لتلقي الإشعارات الفورية، وهي خطوة حيوية لبناء أنظمة أتمتة سريعة الاستجابة وفعالة.

1. ما هو الفرق الجوهري: السحب (Polling) مقابل الدفع (Push)

في الدرس السابق، كان نموذج التواصل هو السحب (Pulling) أو الاستقصاء (Polling). نظامنا (العميل) هو الذي يسحب المعلومات من الخادم بشكل دوري.

الـ Webhooks تقدم نموذجًا معاكسًا تمامًا، وهو الدفع (Pushing). هنا، الخادم هو الذي يدفع بالمعلومات إلى نظامنا فور وقوع حدث معين.

للحصول على توضيح مرئي وممتاز لهذا الفرق، شاهد المقطع التالي.

كما رأيت، بدلًا من أن نسأل باستمرار "هل هناك طلب جديد؟"، نحن نزود YouCan برابط ونقول له: "عندما يأتي طلب جديد، أرسل لي تفاصيله إلى هذا الرابط". هذا هو جوهر الـ Webhooks.

2. كيف تعمل الـ Webhooks؟ (الآلية التقنية)

الآن بعد أن فهمنا المبدأ، دعنا ندخل في التفاصيل التقنية التي طلبتها. عملية إعداد واستقبال الـ Webhook تتم في ثلاث خطوات بسيطة:

1. تعريف الحدث (The Event): تحدد الخدمة المصدر (مثل YouCan) قائمة بالأحداث التي يمكنك الاشتراك فيها. على سبيل المثال: order.created (إنشاء طلب جديد)، order.updated (تحديث طلب)، product.created (إضافة منتج جديد).
2. تسجيل الرابط (Registering the URL): أنت تقوم بتزويد الخدمة المصدر بعنوان URL فريد. هذا العنوان يسمى "Webhook URL" أو "Callback URL"، وهو ينتمي إلى التطبيق الذي سيستقبل البيانات (مثل منصة الأتمتة Make.com). هذا الرابط يجب أن يكون قادرًا على استقبال طلبات HTTP.
3. إرسال البيانات (The Push): عندما يقع الحدث الذي اشتركت فيه (مثلاً، عميل جديد يضع طلبًا)، تقوم الخدمة المصدر (YouCan) تلقائيًا بإرسال طلب HTTP POST إلى الـ URL الذي سجلته. يحتوي جسم (Body) هذا الطلب على جميع تفاصيل الحدث (بيانات الطلب الجديد) في صيغة بيانات، عادةً ما تكون JSON.

3. تجربة أول Webhook عمليًا

لفهم كيفية استقبال البيانات بشكل عملي، سنستخدم أداة مجانية وبسيطة تسمى Webhook.site. هذه الأداة توفر لك رابط URL مؤقتًا "يستمع" لأي بيانات تُرسل إليه ويعرضها لك فورًا.

الآن، دعنا نرى هذه العملية بشكل حي.

هذه التجربة البسيطة هي جوهر ما سنفعله في أنظمتنا. الرابط الذي حصلنا عليه من Webhook.site سيكون لاحقًا رابطًا توفره لنا منصة Make.com لبدء سيناريو الأتمتة.

4. اعتبارات تقنية متقدمة (Deep Dive)

بما أنك تفضل التفاصيل التقنية، من المهم ألا نكتفي بفهم "ماذا" تفعل الـ Webhooks، بل "كيف" نضمن أنها تعمل بشكل آمن وموثوق.

بناءً على ما قرأت، إليك أهم النقاط التي يجب أن تضعها في اعتبارك عند بناء أنظمة حقيقية:

• الأمان (Security): كيف تتأكد من أن البيانات التي وصلت إلى رابطك هي بالفعل من YouCan وليست من جهة خبيثة؟

  • الحل: معظم الأنظمة المحترمة تستخدم ما يسمى بـ التوقيع (Signature). عند إعداد الـ Webhook، يتم تزويدك بـ "سر" (Secret). يقوم YouCan باستخدام هذا السر لتوليد توقيع فريد مع كل طلب يرسله. عند استقبالك للطلب، يمكنك إعادة حساب التوقيع بنفسك ومقارنته بالتوقيع المرسل. إذا تطابقا، فالطلب أصلي.

• الموثوقية (Reliability): ماذا يحدث إذا كان خادمك (أو منصة Make.com) متوقفًا عن العمل للحظة التي أرسل فيها YouCan الـ Webhook؟ هل تضيع البيانات؟

  • الحل: الأنظمة الجيدة لديها آلية إعادة محاولة (Retry Mechanism). إذا فشل إرسال الـ Webhook (مثلاً، لم يستجب خادمك برمز 200 OK)، سيحاول النظام المصدر إعادة إرساله عدة مرات على فترات زمنية متباعدة (e.g., after 1 min, 5 mins, 30 mins).

• عدم التكرار (Idempotency): بسبب آلية إعادة المحاولة، قد يصلك نفس الـ Webhook مرتين. كيف تضمن ألا يقوم نظامك بمعالجة نفس الطلب مرتين (مثلاً، إرسال رسالتي تأكيد لنفس الطلب)؟

  • الحل: يجب أن يكون نظامك قادرًا على التعامل مع التكرار. الطريقة الشائعة هي التحقق من المعرف الفريد للحدث (Event ID) أو الطلب (Order ID). قبل معالجة أي Webhook، يجب أن يتحقق نظامك: "هل قمت بمعالجة هذا المعرف من قبل؟". إذا كانت الإجابة نعم، يتم تجاهل الطلب الجديد.

هذه الاعتبارات هي الفارق بين بناء أتمتة بسيطة للتجربة، وبناء نظام قوي يمكن الاعتماد عليه في بيئة عمل حقيقية.

خلاصة الدرس

لقد قطعنا شوطًا كبيرًا اليوم في فهم الجانب الآخر من التواصل بين التطبيقات:

• الـ APIs تعتمد على نموذج السحب (Polling) حيث يبادر العميل بطلب البيانات.
• الـ Webhooks تعتمد على نموذج الدفع (Push) حيث يبادر الخادم بإرسال البيانات عند وقوع حدث معين.
• تعتبر الـ Webhooks أكثر كفاءة وسرعة للتطبيقات التي تتطلب استجابة فورية، مثل أتمتة الطلبات.
• إعداد Webhook يتطلب URL من النظام المستقبل واشتراك في حدث معين في النظام المصدر.
• للتطبيقات الحقيقية، يجب مراعاة الأمان (التوقيعات)، الموثوقية (إعادة المحاولة)، وعدم التكرار (Idempotency).

الدرس القادم

في تجربة Webhook.site، لاحظت بالتأكيد أن البيانات التي تصل تكون في شكل نص منظم. هذا التنسيق يسمى JSON (JavaScript Object Notation). هو اللغة المشتركة التي تتحدث بها معظم واجهات برمجة التطبيقات الحديثة.

في الدرس القادم، سنتعلم كيفية تحليل استجابة API بصيغة JSON وفهم بنيتها الأساسية. هذه المهارة أساسية لأن كل بياناتك - من المنتجات والطلبات إلى استجابات شركات الشحن - ستصلك بهذا الشكل، ويجب أن تكون قادرًا على قراءتها واستخراج المعلومات التي تحتاجها منها.