ما هو الويب هوك (web hook)؟

مقدمة

ويب هوك هي وسيلة مفيدة بشكل لا يصدق ومواردها خفيفة لتنفيذ ردود فعل الحدث. الويب هوك يوفر آلية بحيث يمكن للتطبيق من جهة الخادم بإبلاغ التطبيق من جهة العميل بحدوث حدث جديد (قد يكون التطبيق من جهة العميل مهتمًا به) قد حدث على الخادم.

الويب هوك يشار إليه أحيانًا باسم "واجهة برمجة التطبيقات العكسية (Reverse APIs)". في واجهات برمجة التطبيقات(APIs)، يستدعي التطبيق من جهة العميل (يستهلك) التطبيق من جهة الخادم. بينما في حالة وجود الويب هوك، فإن جهة الخادم هو الذي يستدعي (يستهلك) الويب هوك (محدد موقع الموارد المُوحّد(URL) لنقطة النهاية الذي يوفره التطبيق من جهة العميل)، أي أنه التطبيق من جهة الخادم الذي يستدعي التطبيق جهة العميل.

تعمل الويب هوك على مفهوم "ردة فعل الحدث" (لا تتصل بي، سأتصل بك إذا كان لديّ شيء جديد)، وبالتالي تتجنب الحاجة إلى إجراء استطلاع مستمر للتطبيق من جهة الخادم بواسطة التطبيق من جهة العميل. إذًا، بدلاً من أن يقوم التطبيق من جهة العميل بالاستقصاء الدائم للتطبيق من جهة الخادم للتحقق من الأحداث الجديدة، يستدعي التطبيق من جهة الخادم التطبيق من جهة العميل (عن طريق استدعاء عميل يوفر محدد موقع الموارد المُوحّد(URL) لويب هوك) في أي وقت يكون فيه جهة الخادم لديه شيء جديد يقدم تقريرًا إلى العميل.

هذا هو المبدأ الأساسي للويب هوك.

فبالتالي، مع الويب هوك يمكنك الحصول على إشعارات الدفع (push notifications) عند حدوث أحداث معينة على الخادم. لن تحتاج إلى استقصاء واجهة برمجة التطبيقات(API) بعد الآن لمعرفة ما إذا كانت هذه الأحداث قد حدثت أم لا. يمكنك فقط "الاشتراك" في أي حدث باستخدام الويب هوك.

 

إذًا، ما هو شكل الويب هوك بالضبط؟

في استدعاءات واجهة برمجة التطبيقات(API) يوفر التطبيق من جهة الخادم للتطبيق من جهة العميل محدد موقع الموارد المُوحّد(URL) لنقطة النهاية التي يمكن للتطبيق من جهة العميل استدعاءها.  وبالتالي، قد تعرض جهة الخادم محدد موقع الموارد المُوحّد(URL) لنقطة النهاية واجهة برمجة التطبيقات(API) التالية لتطبيق نوع لوحة رسائل بسيطة.

 

POST /messages                                                               createNewMessage
GET  /messages/{messageId}                                            readMessage
POST /messages/{messageId}/comments                         postComment
GET  /messages/{messageId}/comments/{commentsId}   readComment

 

يتم كشف محدد موقع الموارد المُوحّد(URL) هذه بواسطة تطبيق من جهة الخادم.

وبالتالي، إذا كان التطبيق من جهة العميل يريد نشر رسالة جديدة إلى الخادم، فإن التطبيق من جهة العميل يدعوه (يستهلك)،

POST /messages

وبالمثل، إذا أراد التطبيق من جانب العميل قراءة تعليق منشور مقابل رسالة معينة على الخادم، فإن التطبيق من جانب العميل يدعوه (يستهلك)،

GET /messages/{messageId}/comments/{commentsId}

لاحظ أن الرسائل والتعليقات يتم إنشاؤها وتخزينها على قاعدة بيانات الخادم، وقراءتها من قاعدة بيانات الخادم، باستخدام واجهات برمجة التطبيقات(APIs) التي يوفرها الخادم (محدد موقع الموارد المُوحّد(URL) لنقطة النهاية).

في حالة الويب هوك، فإن التطبيق من جهة العميل هو الذي يوفر للتطبيق من جهة الخادم محدد موقع الموارد المُوحّد(URL) للاستدعاء، بينما يستدعي التطبيق من جانب الخادم (يستهلك) محدد موقع الموارد المُوحّد(URL) هذا، عند حدوث حدث متصل من جهة الخادم. لذا، فإن الويب هوك هو ببساطة عنوان محدد موقع الموارد المُوحّد(URL) لنقطة النهاية يوفره التطبيق من جهة العميل للتطبيق من جهة الخادم. في حالة مثالنا على لوحة الرسائل البسيطة، فقد يبدو الأمر هكذا.

 

{  

“newCommentWebhook”: “https://clientdomain.com/webhook/newcomment" 

}

 

فبالتالي، فإن الويب هوك ليس سوى محدد موقع الموارد المُوحّد(URL) البسيط لنقطة النهاية مقدم من جهة العميل. يجب تمرير محدد موقع الموارد المُوحّد(URL) لنقطة النهاية بواسطة التطبيق من جهة العميل إلى التطبيق جهة الخادم في مرحلة ما قبل استدعاء الويب هوك من جهة الخادم.

دعنا نقول إننا نريد من التطبيق من جهة الخادم أن يبلغ التطبيق من جهة العميل كلما تم نشر تعليق جديد مقابل رسالة معينة. في هذه الحالة، عندما يتم نشر تعليق جديد على قاعدة البيانات من جانب الخادم، يجب على التطبيق من جانب الخادم (بعد نشر التعليق على قاعدة البيانات) استدعاء محدد موقع الموارد المُوحّد(URL) للويب هوك أعلاه، لإعلام العميل بوجود تعليق جديد. فبالتالي، باستخدام الويب هوك، يمكن لجهة الخادم إخطار جهة العميل بالحدث ذي الصلة (على سبيل المثال، تم نشر تعليق جديد).

من منظور التنفيذ، يتعين على التطبيق من جهة الخادم تصميم محدد موقع الموارد المُوحّد(URL) لنقطة النهاية الخاصة به بحيث يكون هناك بعض معلمات العنصر النائب(placeholder parameter)، والتي تسمح للتطبيقات من جهة العميل بتمرير محدد موقع الموارد المُوحّد(URL) للويب هوك. يمكن القيام بذلك واجهة برمجة التطبيقات(API) "هيكل الطلب" من جهة الخادم والتي تحتوي على معلمة لمحدد موقع الموارد المُوحّد(URL) الخاصة بالويب هوك.

ثانياً، يجب أن يكون للتطبيق من جهة الخادم آلية لتخزين العميل في نقطة نهاية الويب هوك المقدمة، بحيث يمكن استدعاءه من جهة الخادم عند الطلب. وبالتالي، في مثالنا، يجب أن يحتوي نص طلب واجهة برمجة التطبيقات (API) من جهة الخادم على بعض المعلمات، حيث يمكن للتطبيق من جهة العميل تضمين محدد موقع الموارد المُوحّد(URL) لويب هوك.

 

استخدام الويب هوك للإشعارات مقابل تسليم الحمولات (web hook for notifications vs. delivering payloads)

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

بمجرد استلام إشعار بتغيير الحالة، يمكن استدعاء واجهة API الآمنة المنفصلة من التطبيق جهة العميل، لتلقي الحمولة الفعلية. يسمح فصل الاهتمامات (SoC) هذا بتحسين قابلية التوسع وموثوقية تكامل واجهة برمجة التطبيقات (API) الشاملة.

 

مصادر

يتيح لك الموقع التالي اختبار مفهوم الويب هوك https://webhook.site/  

يقوم بإنشاء عنوان URL فريد للويب هوك يمكنك استدعاءه بواسطة التطبيق الخاص بك لاختبار ميزة رد الاستدعاء (إبلاغ) في الويب هوك.

المصدر: 

https://codeburst.io/what-are-webhooks-b04ec2bf9ca2

 

كلمات دليلية: تكنولوجيا ويب