"الويب هوك مقابل واجهة برمجة التطبيقات" (Webhook vs API) هو أحد تلك المصطلحات التي تخفي سؤالًا أفضل تحتها. إذا قمت بربط مدفوعات Stripe أو تكامل GitHub من قبل، فربما تساءلت: أليس الويب هوك مجرد واجهة برمجة تطبيقات (API)؟ الإجابة المختصرة هي أن الويب هوك ليس نقيض واجهة برمجة التطبيقات (API). بل هو واجهة برمجة تطبيقات تعمل في الاتجاه الآخر.
يوضح هذا الدليل اللبس. ستتعرف على ما يفصل بين الاثنين فعليًا، ولماذا لا يعدان خيارًا حصريًا، وكيف تختار الأنسب لمهمة معينة. إذا كنت تقوم ببناء أو اختبار التكاملات، فإن Apidog يتيح لك تصميم واختبار واجهات برمجة التطبيقات (API) العادية ومستقبلات الويب هوك في مكان واحد، بحيث يتوقف التمييز عن كونه مجرد مفهوم نظري.
الإجابة المختصرة
- واجهة برمجة التطبيقات (API) العادية، من نوع طلب-استجابة التي يقصدها معظم الناس، تنتظر منك أن تطلب. أنت ترسل طلبًا، وهي ترسل استجابة. أنت تتحكم في التوقيت.
- الويب هوك يعكس ذلك. يرسل المزود البيانات إلى خادمك لحظة حدوث شيء ما. أنت لا تطلب؛ بل يتم إعلامك.
- كلاهما ينتقل عبر HTTP. وكلاهما يرسل عادة بيانات JSON. غالبًا ما يطلق على الويب هوك "واجهة برمجة تطبيقات عكسية" أو "واجهة برمجة تطبيقات دفع" لهذا السبب تحديدًا.
لذا، ليست المسألة "ويب هوك مقابل واجهة برمجة تطبيقات". بل هي "سحب مقابل دفع".
ماذا يقصد الناس بـ "API"
عندما يقول أحدهم "استدعِ الـ API"، فإنهم عادة ما يقصدون واجهة برمجة تطبيقات REST: واجهة طلب-استجابة حيث يقوم الكود الخاص بك بإجراء طلب HTTP إلى عنوان URL ويحصل على بيانات في المقابل. أنت تتحكم في وقت تشغيلها. هل تريد آخر حالة للطلب؟ أنت تستدعي GET /orders/123 وتقرأ الاستجابة. لا يحدث شيء حتى تطلب أنت.
هذا هو نموذج السحب. إنه بسيط، ويمكن التنبؤ به، ومناسب عندما تحتاج إلى بيانات عند الطلب. المقايضة: لالتقاط أي تغيير، يجب أن تستمر في الطلب. إذا كنت تريد مراجعة لكيفية بناء الطلب والاستجابة، راجع فهم هيكل طلب واجهة برمجة التطبيقات (API).
ما هو الويب هوك
الويب هوك هو رد نداء (callback) HTTP يحدده المستخدم. تقوم بتسجيل عنوان URL لدى مزود، على سبيل المثال https://yourapp.com/webhooks/stripe. عندما يحدث حدث على جانبهم، يرسل المزود طلب HTTP POST إلى عنوان URL الخاص بك مع بيانات الحدث.
الآن أنت المُستقبِل، وليس المتصل. ينتظر خادمك، ويدفع المزود تحديثًا عندما يكون هناك شيء يستحق إخبارك به. هذا هو نموذج الدفع. الويب هوكس هي الطريقة التي يخبرك بها Stripe أن دفعة قد تمت، وكيف يخبرك GitHub بأنه تم دفع كود، وكيف يخبر Slack تطبيقك بأن شخصًا ما قام بتشغيل أمر. للحصول على نظرة أعمق على جانب الاستقبال، راجع ما هو الويب هوك API.
الويب هوك مقابل واجهة برمجة التطبيقات (API): الفرق الجوهري
| واجهة برمجة تطبيقات عادية (REST) | الويب هوك | |
|---|---|---|
| من يبدأ التبادل | أنت (العميل) | المزود (الخادم) |
| النموذج | طلب-استجابة (سحب) | مبني على الأحداث (دفع) |
| التوقيت | كلما قمت بالاستدعاء | لحظة وقوع الحدث |
| الاتجاه | أنت تستدعي المزود | المزود يستدعي نقطة النهاية الخاصة بك |
| الأفضل لـ | البيانات والإجراءات حسب الطلب التي تبدأها | الاستجابة للأحداث التي لا يمكنك التنبؤ بها |
| التكلفة الرئيسية | يجب عليك الاستقصاء (polling) لالتقاط التغييرات | يجب عليك استضافة وتأمين نقطة نهاية عامة |
الصف الأكثر أهمية هو الأول. اتجاه الاستدعاء هو الفرق كله. كل شيء آخر يتبع ذلك.
"أليس الويب هوك مجرد واجهة برمجة تطبيقات (API)؟" الإجابة الصادقة
نعم ولا، والفارق الدقيق يستحق فهمه جيدًا.
يستخدم الويب هوك نفس اللبنات الأساسية لأي واجهة برمجة تطبيقات: HTTP، عنوان URL، رؤوس، وجسم JSON. وبهذا المعنى، فإن الويب هوك هو استدعاء واجهة برمجة تطبيقات؛ حيث يعمل المزود كعميل وتعمل نقطة النهاية الخاصة بك كخادم. توثّق العديد من الفرق الويب هوكس الخاصة بها بجانب نقاط نهاية REST الخاصة بها. حتى OpenAPI 3.1 أضاف حقلًا مخصصًا webhooks لوصفها، ويمكن لـ Apidog التقاطها بنفس الطريقة (راجع ردود نداء OpenAPI والويب هوكس).
لذا، فإن الصياغة الدقيقة هي كالتالي: الويب هوك هو نمط محدد من الاتصال بواجهة برمجة التطبيقات، وليس تقنية منفصلة. عندما يقول الناس "ويب هوك مقابل واجهة برمجة تطبيقات"، فإن ما يقارنونه حقًا هو واجهة برمجة تطبيقات طلب-استجابة للمزود مقابل آلية دفع الأحداث لنفس المزود. كلاهما ينتمي إلى نفس سطح المنتج.
متى تستخدم أي منهما
استخدم استدعاء واجهة برمجة التطبيقات العادي عندما:
- تحتاج إلى بيانات في لحظة معينة، مثل تحميل صفحة أو تشغيل تقرير.
- تقوم بإجراء: إنشاء دفعة، تحديث سجل، إرسال رسالة.
- تتغير البيانات وفقًا لجدولك الزمني، وليس جدول المزود.
استخدم الويب هوك عندما:
- تحتاج إلى معرفة اللحظة التي يتغير فيها شيء ما ولا يمكنك التنبؤ بها.
- سيكون الاستقصاء (Polling) مضيعة، مثل التحقق كل بضع ثوانٍ من حدث يحدث مرتين في اليوم.
- يتحكم المزود في التوقيت: تتم تسوية دفعة، يكتمل بناء، ينتهي معالجة ملف.
إذا كان خيارك الحقيقي بين الويب هوكس وإعادة التحقق المستمر من نقطة نهاية، فإن هذه المقايضة المحددة لها دليلها الخاص: الويب هوكس مقابل الاستقصاء (Polling).
يعملان معًا، وهذا هو المعتاد
يتلاشى إطار "الويب هوك مقابل واجهة برمجة التطبيقات" في الممارسة العملية لأن عمليات التكامل الحقيقية تستخدم كلاهما. Stripe هو المثال الكلاسيكي:
- أنت تستدعي واجهة برمجة تطبيقات Stripe (طلب-استجابة) لإنشاء نية دفع.
- يقوم Stripe بمعالجتها في الخلفية.
- يستدعي Stripe الويب هوك الخاص بك (دفع الحدث) عندما تنجح أو تفشل الدفعة.
كنت بحاجة إلى واجهة برمجة التطبيقات لبدء الإجراء، وإلى الويب هوك لمعرفة النتيجة. لا يحل أحدهما محل الآخر. يكاد يكون التكامل الموثوق به دائمًا ما يزاوج بين واجهة برمجة تطبيقات صادرة للإجراءات وويب هوك وارد للأحداث. لمزيد من المعلومات حول نمط التصميم الأوسع، راجع كيفية بناء واجهات برمجة تطبيقات مبنية على الأحداث.
الويب هوكس مقابل الويب سوكيتس مقابل الاستقصاء (Polling)
هناك ثلاثة مصطلحات تتشابك معًا، لذا إليك نسخة من سطر واحد لكل منها:
- الويب هوك مقابل الاستقصاء (Polling): كلاهما يبقيك على اطلاع؛ الاستقصاء يسأل مرارًا وتكرارًا، بينما الويب هوك ينتظر لكي يتم إخباره.
- الويب هوك مقابل الويب سوكيت (WebSocket): الويب هوك هو طلب HTTP POST واحد لكل حدث؛ الويب سوكيت هو اتصال مستمر ثنائي الاتجاه للتدفقات المستمرة. تفصيل كامل في الويب هوك مقابل الويب سوكيت.
- الويب هوك مقابل واجهة برمجة التطبيقات (API): الموضوع هنا؛ يتعلق الأمر باتجاه الاستدعاء.
كيفية تصميم واختبار كليهما باستخدام Apidog
تطوير الويب هوكس قد يكون محرجًا. يجب أن تستقبل نقطة النهاية الخاصة بك طلبات POST حقيقية قبل أن تتمكن من الوثوق بها، ولن يقوم المزودون بإطلاق أحداث اختبار وفقًا لجدولك الزمني.
يتعامل Apidog مع جانبي العلاقة:
- صمم واختبر نقاط نهاية الطلب-الاستجابة الخاصة بك باستخدام سيناريوهات الاختبار المرئية والتأكيدات، دون الحاجة إلى البرمجة النصية.
- أرسل طلب POST مصممًا إلى مستقبل الويب هوك الخاص بك، حتى تتمكن من بناء وتأكيد المعالج قبل وصول الأحداث الحقيقية.
- وثّق الويب هوكس الصادرة الخاصة بك جنبًا إلى جنب مع نقاط نهاية REST باستخدام OpenAPI، حتى يرى المستهلكون العقد الكامل.
نظرًا لأن التصميم والمحاكاة والاختبار والتوثيق جميعها موجودة في مساحة عمل واحدة، فإنك تتعامل مع مستقبل الويب هوك كأي عقد API آخر. قم بتنزيل Apidog لبناء واختبار كلاهما في مكان واحد.
الأسئلة الشائعة
هل الويب هوك هو واجهة برمجة تطبيقات (API)؟ الويب هوك هو نمط من أنماط الاتصال بواجهة برمجة التطبيقات (API)، وليس تقنية منفصلة. يستخدم HTTP وعنوان URL وحمولة JSON مثل أي استدعاء لواجهة برمجة تطبيقات. الفرق هو أن المزود يستدعي نقطة النهاية الخاصة بك بدلاً من أن تستدعي أنت نقطة نهايته، ولهذا السبب يسميه البعض واجهة برمجة تطبيقات عكسية.
هل يمكنك استخدام الويب هوك بدون واجهة برمجة تطبيقات (API)؟ نادرًا بمفرده. معظم سير العمل يستدعي واجهة برمجة تطبيقات المزود لبدء شيء ما، ثم يعتمد على الويب هوك لتلقي الرد. الاثنان يكملان بعضهما البعض. راجع ما هو الويب هوك API لمعرفة كيفية بناء جانب الاستقبال.
هل الويب هوك أسرع من واجهات برمجة التطبيقات (APIs)؟ للاستجابة للأحداث، نعم، لأنك تتلقى إشعارًا فور حدوث شيء ما بدلاً من الاستقصاء (polling) والانتظار حتى فحصك التالي. لجلب البيانات عند الطلب، استدعاء واجهة برمجة التطبيقات المباشر هو الأداة المناسبة.
هل تحل الويب هوكس محل واجهات برمجة تطبيقات REST؟ لا. إنها تغطي احتياجات مختلفة: REST للطلبات والإجراءات حسب الطلب، والويب هوكس لإشعارات الأحداث في الوقت الفعلي. عادة ما تعمل أنظمة الإنتاج بكلا النوعين.
هل الويب هوك آمن؟ يكشف الويب هوك عن نقطة نهاية عامة، لذا يجب عليك التحقق من أن كل طلب حقيقي، وعادة ما يتم ذلك عن طريق التحقق من التوقيع الذي يرسله المزود. راجع التحقق من توقيع الويب هوك.
الخلاصة
اتضح أن إطار "الويب هوك مقابل واجهة برمجة التطبيقات (API)" خاطئ. واجهة برمجة التطبيقات العادية تنتظر منك أن تطلب؛ الويب هوك يخبرك لحظة حدوث شيء ما. أحدهما يسحب، والآخر يدفع، ومعظم عمليات التكامل تشغّل كلاهما معًا. اختر استدعاء واجهة برمجة التطبيقات عندما تتحكم في التوقيت، والويب هوك عندما يتحكم المزود.
عندما تكون مستعدًا لبناء أي من الجانبين، قم بتصميم واجهاتك ونقاط نهاية الويب هوك الخاصة بك واختبارها معًا في Apidog.