webhook چیست؟

احتمالاً در مستندات APIها یا هنگام طراحی معماری‌های رویدادمحور (Event-Driven)، بارها با اصطلاح وب هوک (Webhook) برخورد کرده‌اید. برای درک بهتر این مفهوم در برنامه‌نویسی، منطق ارسال نوتیفیکیشن‌ (Push Notification) را در نظر بگیرید، شما برای خواندن یک پیام جدید، مدام اپلیکیشن را باز نمی‌کنید تا سرور را چک کنید، بلکه خود سیستم به‌محض دریافت پیام، شما را باخبر می‌کند.

وب‌هوک‌ها دقیقاً همین الگوی Push را در سطح ارتباطات سرور-به-سرور پیاده‌سازی می‌کنند. در واقع، به‌جای اینکه برنامه‌ی شما به‌صورت مداوم و زمان‌بندی‌شده سرور را برای دریافت داده‌های جدید ریکوئست‌باران کند، سرور موظف می‌شود دیتای مربوط به هر رویداد (Event) را در همان لحظه وقوع به سمت برنامه شما ارسال کند.

در این مقاله از بلاگ کندو، بررسی می‌کنیم که دقیقاً وب هوک چیست، چه تفاوتی با APIهای سنتی دارد و چگونه می‌توانید از آن برای تبادل آنی داده‌ها و کاهش بار ترافیکی سرورهایتان استفاده کنید.

مکانیزم Webhook چیست و چگونه کار می‌کند؟

اگر بخواهیم از دیدگاه معماری سیستم‌ها بررسی کنیم که مکانیزم وب هوک چیست، باید آن را یک Callback از جنس HTTP (معمولاً با متد POST) بدانیم که توسط برنامه‌نویس یا مدیر سیستم پیکربندی می‌شود. در معماری‌های مبتنی بر رویداد (Event-Driven)، وب‌هوک دقیقاً نقش یک پل ارتباطی بلادرنگ را بازی می‌کند.

به محض اینکه یک رویداد (Event) خاص در سیستم مبدأ رخ می‌دهد، این سیستم داده‌های مربوط به آن اتفاق را در قالب یک بسته اطلاعاتی به نام Payload (اغلب با فرمت JSON یا XML) آماده کرده و مستقیماً به یک URL در سیستم مقصد ارسال می‌کند.

روند کار یک webhook را می‌توان در این مراحل خلاصه کرد:

• وقوع رویداد (Triggering Event): تغییر وضعیت در سیستم مبدأ. (مثلاً لاگین موفق کاربر، آپدیت شدن یک دیتابیس یا پرداخت موفق در درگاه).
• تولید Payload: کامپایل و بسته‌بندی داده‌های حیاتیِ همان رویداد توسط سیستم مبدأ.
• ارسال درخواست HTTP: شلیک داده‌ها به سمت Endpoint (آدرس گیرنده) در سیستم مقصد.
• اعتبارسنجی (Verification): بررسی امنیتی درخواست در سیستم مقصد برای اطمینان از صحت فرستنده.

سناریوی عملی در محیط کار:

فرض کنید مدیریت یک مخزن گیت‌هاب (GitHub) را بر عهده دارید و تیم DevOps شما باید به محض Push شدن کدهای جدید، یک نوتیفیکیشن در تلگرام یا Slack دریافت کند. با انجام تنظیمات مرتبط با ساخت وب هوک در گیت‌هاب، یک مسیر مستقیم ایجاد می‌کنید. گیت‌هاب به محض دریافت کامیت جدید، اطلاعات تغییرات را از طریق یک درخواست HTTP به URL ربات پیام‌رسان شما می‌فرستد.

نکته فنی امنیتی: در معماری واقعی، سیستم مقصد نباید صرفاً یک دریافت‌کننده چشم‌بسته باشد. برای جلوگیری از حملات جعل درخواست (Spoofing)، سیستم مقصد باید قابلیت اعتبارسنجی داشته باشد. در ابزارهایی مثل گیت‌هاب، همراه با Payload یک Signature Header مبتنی بر مکانیزم رمزنگاری HMAC ارسال می‌شود. گیرنده با بررسی این هدر مطمئن می‌شود که درخواست دقیقاً از سمت گیت‌هاب آمده و توسط شخص ثالث دستکاری نشده است.

انواع وب‌هوک در پروژه‌های واقعی

اگرچه مکانیزم ارسال داده در تمام وب‌هوک‌ها یکسان است (ارسال درخواست HTTP POST)، اما در معماری نرم‌افزار، وب‌هوک‌ها را بر اساس ماهیت داده‌ها (Payload) و منطق تجاری (Business Logic) به سه دسته اصلی تقسیم می‌کنند. شناخت این دسته‌بندی‌ها به شما کمک می‌کند تا در سناریوهای مختلف، ابزار درستی را پیاده‌سازی کنید:

۱. وب‌هوک‌های مالی (تراکنش‌ها و درگاه‌های پرداخت)

حیاتی‌ترین کاربرد وب‌هوک در سیستم‌های مالی و فروشگاهی است. در بازار کار ایران، پیاده‌سازی وب‌هوکِ درگاه‌های پرداخت (مثل زرین‌پال یا درگاه‌های بانکی) یک تسک روزمره برای توسعه‌دهندگان بک‌اند محسوب می‌شود.

• سناریوی عملی: کاربر در سایت شما دکمه پرداخت را می‌زند و به درگاه بانک منتقل می‌شود. پس از انجام تراکنش، بانک به جای اینکه منتظر بماند تا سرور شما وضعیت را پیگیری کند، بلافاصله یک وب‌هوک حاوی شناسه تراکنش (Token) و وضعیت موفق/ناموفق بودن آن به Endpoint سرور شما ارسال می‌کند تا سفارش کاربر در دیتابیس ثبت نهایی شود.

۲. وب‌هوک‌های مانیتورینگ و CI/CD (مدیریت رویدادها)

تیم‌های زیرساخت و DevOps وابستگی شدیدی به این نوع از وب‌هوک‌ها دارند. هدف در اینجا، خودکارسازی فرآیندها و اطلاع‌رسانی بلادرنگ است.

• سناریوی عملی: سیستم مانیتورینگ Zabbix کانفیگ می‌شود تا در صورت بالا رفتن مصرف CPU سرور از ۹۰٪، یک وب‌هوک به API تلگرام بفرستد تا ادمین‌ها آلارم دریافت کنند. یا در فرآیندهای CI/CD، گیت‌لب (GitLab) با ارسال یک وب‌هوک به Jenkins، دستور شروع فرآیند Build و تست خودکار کدهای جدید را صادر می‌کند.

۳. وب‌هوک‌های احراز هویت و مدیریت کاربران (Identity & Auth)

سرویس‌های مدیریت هویت (مانند Keycloak یا Auth0) برای همگام‌سازی اطلاعات کاربران با پایگاه داده داخلی برنامه‌ها از وب‌هوک استفاده می‌کنند.

• سناریوی عملی: زمانی که کاربر پروفایل خود را در سیستم یکپارچه (SSO) آپدیت می‌کند یا رمز عبورش به دلیل تلاش‌های ناموفق قفل می‌شود، سیستم احراز هویت یک وب‌هوک حاوی رویداد user.updated یا user.locked به تمام میکروسرویس‌های متصل ارسال می‌کند تا کش (Cache) خود را به‌روز کنند.

نکته فنی (مدل‌های اجرایی وب‌هوک)

فارغ از نوع داده‌ها، وب‌هوک‌ها در سطح کدنویسی به دو شکل اجرا می‌شوند (موردی که در مصاحبه‌های فنی زیاد پرسیده می‌شود):

1. وب‌هوک‌های ناهمگام (Asynchronous): مدل استاندارد و رایج (Fire-and-Forget). سیستم مبدأ داده را می‌فرستد و به کار خود ادامه می‌دهد. تاخیر یا قطعی سرور مقصد، اختلالی در روند سیستم مبدأ ایجاد نمی‌کند (مثل ارسال نوتیفیکیشن پرداخت).
2. وب‌هوک‌های همگام (Synchronous): سیستم مبدأ درخواست را می‌فرستد و فرآیند اصلی خود را متوقف می‌کند (Block) تا پاسخ سرور مقصد را دریافت کند. از این مدل در موارد حساس، مانند اعتبارسنجی‌های پیش از ثبت‌نام (Pre-registration Validation) استفاده می‌شود که تایید سرور مقصد برای ادامه کار الزامی است.

راهنمای ۳ مرحله‌ای پیاده‌سازی و تست Webhook

پیاده‌سازی وب‌هوک برخلاف APIهای پیچیده، نیازمند معماری سنگینی نیست، اما برای اجرای صحیح باید ارتباط بین سیستم «مبدا» (فرستنده رویداد) و سیستم «مقصد» (گیرنده) به درستی کانفیگ شود. برای راه‌اندازی و تست یک وب‌هوک در محیط واقعی، این ۳ مرحله را طی کنید:

۱. ساخت و آماده‌سازی Endpoint (در سمت گیرنده)

ابتدا باید در اپلیکیشن یا سرور خود، یک مسیر (Route) عمومی بسازید که منتظر دریافت داده‌ها باشد. این Endpoint معمولاً یک متد POST است که داده‌ها را در قالب JSON دریافت می‌کند.

• Best Practice: روتِ وب‌هوک شما باید در سریع‌ترین زمان ممکن (زیر چند ثانیه) کد وضعیت 200 OK یا 202 Accepted را به سرور مبدا برگرداند. اگر پردازش داده‌ها زمان‌بر است، آن را به یک Background Job بسپارید تا مبدا دچار Time-out نشود.

۲. ثبت URL در سرویس مبدأ و انتخاب رویدادها (در سمت فرستنده)

حالا باید آدرس Endpointای که در مرحله قبل ساختید را در پنل سرویس‌دهنده (مثلاً گیت‌هاب، زرین‌پال یا GitLab) ثبت کنید.

• تعیین Eventها: سرویس‌دهنده‌ها به شما اجازه می‌دهند دقیقاً مشخص کنید چه رویدادی باید ارسال شود (مثلاً فقط رویداد pull_request یا payment.success). انتخاب دقیق رویدادها از ارسال ترافیک اضافی (Overhead) به سرور شما جلوگیری می‌کند.
• تنظیم Secret Key: در همین مرحله معمولاً یک رشته متنی به‌عنوان Secret تنظیم می‌کنید تا در آینده بتوانید هویت فرستنده درخواست را اعتبارسنجی کنید (جلوگیری از حملات Spoofing).

۳. تست و دیباگ لوکال با ابزارهای شبیه‌ساز (Hands-on Experience)

یکی از چالش‌های برنامه‌نویسان جونیور، تست وب‌هوک روی سیستم شخصی (Localhost) است، زیرا سرویس‌های خارجی نمی‌توانند به آدرس‌های لوکال (مثل 127.0.0.1) درخواست بفرستند. برای حل این مشکل و مانیتورینگ Payloadها از ابزارهای زیر استفاده کنید:

• ابزار ngrok: این ابزار قدرتمند، یک تونل امن (Public URL) می‌سازد و آن را به پورت لوکال شما متصل می‌کند. با دادن لینک ngrok به سرویس‌دهنده، می‌توانید وب‌هوک‌ها را مستقیماً روی محیط توسعه خود دریافت و دیباگ کنید.
• سایت Webhook.site: اگر هنوز کدی ننوشته‌اید و فقط می‌خواهید ساختار JSON ارسالی از سمت مبدأ را بررسی کنید، این سایت یک URL موقت به شما می‌دهد. با ثبت این URL در مبدا، تمام Headerها و Payloadهای ارسالی در لحظه و روی مرورگر به شما نمایش داده می‌شوند.

کاربردهای عملی و سناریوهای واقعی Webhook

وب‌هوک‌ها جایگزین مناسبی برای معماری Polling هستند. در اکوسیستم فعلی توسعه نرم‌افزار، تقریباً هر سرویسی که نیاز به ارتباطات Real-time داشته باشد، از وب‌هوک استفاده می‌کند. برخی از کاربردهای عمومی و رایج آن عبارتند از:

• درگاه‌های پرداخت (Payment Gateways): اطلاع‌رسانی آنی به سرور فروشگاه پس از موفقیت یا شکست تراکنش کاربر (مثل زرین‌پال یا Stripe).
• سیستم‌های CI/CD: ارسال تریگر از سمت گیت‌هاب (GitHub) یا گیت‌لب به سرورهای Jenkins یا داکر برای شروع فرآیند Build و Deploy پس از هر Push.
• مدیریت ارتباط با مشتری (CRM): همگام‌سازی اطلاعات کاربران بین پلتفرم‌های مختلف (مثلاً اضافه شدن یک لید جدید در سایت و ایجاد خودکار پروفایل در HubSpot یا ابزارهای ایمیل مارکتینگ).
• سیستم‌های مانیتورینگ: ارسال آلرت‌های لحظه‌ای به کانال‌های Slack یا Discord در صورت افتادن سرور یا بالا رفتن مصرف CPU.

اما برای درک عمیق‌تر این مکانیزم، بیایید یک سناریوی بومی و کاربردی را به عنوان مطالعه موردی (Case Study) بررسی کنیم.

بررسی موردی: اتوماسیون مالی در اپلیکیشن رسید

اپلیکیشن مدیریت پیامک رسید، یک راه‌حل هوشمند برای مدیریت، مسیریابی و ارسال خودکار پیامک‌ها است. کارکرد اصلی این اپلیکیشن حذف دخالت دستی در مدیریت پیام‌هاست، به این صورت که کاربر می‌تواند قوانین (Rules) و شروط خاصی تعریف کند تا مشخص شود چه پیامک‌هایی، در چه شرایطی و برای چه کسانی (تیم فروش، پشتیبانی یا حتی اعضای خانواده) فوروارد شوند. هدف اصلی، جلوگیری از گم شدن پیام‌های حساس و رساندن داده‌ها به افراد یا سیستم‌های درست است.

نقش وب‌هوک در تخصصی‌سازی و اتوماسیون فرآیندهای «رسید» چیست؟

فرض کنید شما یک فروشگاه اینترنتی یا یک تیم حسابداری دارید و می‌خواهید به محض دریافت پیامک واریز وجه بانکی، سند آن در سیستم حسابداری شما ثبت شود یا وضعیت سفارش مشتری به «پرداخت‌شده» تغییر کند.

در اینجا فناوری وب‌هوک به عنوان هسته اصلی اتوماسیون وارد عمل می‌شود:

1. تشخیص رویداد (Event): اپلیکیشن رسید، پیامک واریزی را بر اساس قوانینی که تعریف کرده‌اید (مثلاً فرستنده پیامک بانک ملت باشد) شناسایی می‌کند.
2. ارسال آنی (Push): به جای اینکه نرم‌افزار حسابداریِ شما دائماً از اپلیکیشن رسید بپرسد «آیا پیامک جدیدی آمده؟»، اپلیکیشن رسید دیتای پیامک دریافتی را در قالب یک فایل JSON (شامل متن پیام، شماره فرستنده و زمان دریافت) بسته‌بندی می‌کند.
3. یکپارچه‌سازی (Integration): این داده‌ها بلافاصله از طریق یک درخواست HTTP POST به Endpoint (URL وب‌هوک) که شما در سرور حسابداری یا CRM خود تنظیم کرده‌اید، ارسال می‌شود.

با این پیاده‌سازیِ مبتنی بر رویداد (Event-driven)، پردازش فرآیندهای مالی و ارتباطی به یک اتوماسیون بی‌نقص تبدیل می‌شود. سیستم‌ها بدون نیاز به منابع سخت‌افزاری اضافه برای سرکشی‌های مداوم، در کسری از ثانیه آپدیت شده و خطای انسانی در ثبت اطلاعات به صفر می‌رسد.

تفاوت ساختاری Webhook و API؛ چه زمانی از کدام استفاده کنیم؟

یکی از پرتکرارترین سوالات در مصاحبه‌های فنی و معماری نرم‌افزار، تفاوت بین API و Webhook است. اگرچه هر دو برای ارتباط بین سیستم‌ها بر بستر پروتکل HTTP استفاده می‌شوند، اما تفاوت آن‌ها در جهت جریان داده (Data Flow) و نحوه شروع ارتباط است.

به زبان ساده:

معماری Webhook (مدل Push): رویدادی در سرور رخ می‌دهد، سرور داده‌ها را به کلاینت ارسال می‌کند. در اینجا وب‌هوک به عنوان یک Reverse API یا API معکوس عمل می‌کند.

معماری API (مدل Pull): کلاینت درخواست می‌دهد، سرور پاسخ می‌دهد. کلاینت آغازکننده (Initiator) است.

چه زمانی از API استفاده کنیم؟

زمانی که کلاینت نیاز به کنترل زمان و نوع داده‌های دریافتی دارد. مثلاً:

• نمایش لیست آخرین مقالات سایت (درخواست GET).
• ایجاد یک کاربر جدید در دیتابیس (درخواست POST).
• به‌روزرسانی یا حذف یک رکورد خاص (درخواست‌های PUT یا DELETE).

در این سناریوها، کلاینت تصمیم می‌گیرد چه زمانی ارتباط برقرار شود.

چه زمانی از Webhook استفاده کنیم؟

زمانی که کلاینت باید در لحظه نسبت به یک رویداد خارجی (Event) واکنش نشان دهد، بدون اینکه دائماً وضعیت را چک کند. مثلاً:

• دریافت نوتیفیکیشن موفقیت‌آمیز بودن پرداخت از سمت درگاه بانکی.
• اطلاع‌رسانی درباره تبدیل فرمت یک ویدیو در سرور ابری.
• دریافت وضعیت تحویل پیامک از ارائه‌دهنده (Delivery Report).

API برای «عملیات مستقیم و کنترل‌شده» است، در حالی که Webhook برای «گوش دادن به رویدادهای ناهمگام (Asynchronous Events)» طراحی شده است. توسعه‌دهندگان ارشد معمولاً ترکیبی از هر دو را در معماری میکروسرویس‌ها استفاده می‌کنند.

چرا باید به جای Polling تکراری، از وب‌هوک استفاده کنیم؟

پیش از فراگیر شدن وب‌هوک‌ها، روش استاندارد برای اطلاع از تغییرات سرور، تکنیکی به نام Polling بود. در روش Polling، کلاینت در بازه‌های زمانی مشخص (مثلاً هر ۵ ثانیه) به API سرور ریکوئست می‌زند و می‌پرسد: «آیا دیتای جدیدی برای من داری؟»

در ۹۹ درصد مواقع، پاسخ سرور «خیر» است. این معماری در مقیاس بالا (Scale-up) یک فاجعه‌ی مهندسی محسوب می‌شود. جایگزینی Polling با Webhook مزایای فنی زیر را به همراه دارد:

• کاهش چشمگیر بار سرور (Server Load):

در روش Polling، صدها یا هزاران کلاینت به طور همزمان در حال ارسال ریکوئست‌های بی‌فایده به سرور هستند. این کار باعث اتلاف شدید منابع پردازشی (CPU)، حافظه (RAM) و پهنای باند می‌شود. وب‌هوک ترافیک شبکه را تنها به لحظه‌ی وقوع رویداد محدود می‌کند.

• ارتباط بلادرنگ (Real-time) واقعی:

در Polling، بین وقوع رویداد و باخبر شدن کلاینت همیشه یک تاخیر (Latency) وجود دارد (وابسته به فاصله زمانی بین ریکوئست‌ها). وب‌هوک این تاخیر را از بین می‌برد و داده‌ها در میلی‌ثانیه و دقیقاً پس از رخ دادن رویداد، Push می‌شوند.

• جلوگیری از خطای 429 (Too Many Requests):

اکثر سرویس‌دهنده‌های مدرن دارای محدودیت درخواست (Rate Limiting) هستند. اگر سیستمی با متد Polling دائماً ریکوئست ارسال کند، خیلی زود با خطای HTTP 429 بلاک می‌شود. معماری رویدادمحورِ وب‌هوک، نیاز به ریکوئست‌های مداوم کلاینت را حذف کرده و ریسک محدودیت نرخ (Rate Limit) را از بین می‌برد.

به طور خلاصه، در اکوسیستم فعلی توسعه بک‌اند، اصرار بر استفاده از Polling برای چک کردن رویدادها، نشان‌دهنده طراحی ضعیف سیستم (Anti-pattern) است و وب‌هوک استانداردِ قطعی برای این سناریوها به شمار می‌رود.

پروتکل‌های امنیت Webhook

از آنجا که Endpoint مربوط به دریافت وب‌هوک در واقع یک آدرس عمومی (Public URL) روی اینترنت است، هر کسی می‌تواند به آن ریکوئست ارسال کند. بزرگترین دغدغه ادمین‌ها و توسعه‌دهندگان جونیور در پیاده‌سازی این معماری، جلوگیری از دریافت درخواست‌های فیک (Fake Requests) و حملات Spoofing است.

اگر امنیت در این لایه رعایت نشود، یک هکر مهاجم می‌تواند با ارسال یک پی‌لود (Payload) جعلی، سیستم شما را فریب داده و به عنوان مثال، وضعیت یک سفارش پرداخت‌نشده را به «موفق» تغییر دهد. برای ایمن‌سازی این مسیر، پیاده‌سازی پروتکل‌های امنیت استاندارد کاملاً الزامی است. در ادامه ۳ روش اصلی و عملیاتی برای اعتبارسنجی وب‌هوک‌ها را بررسی می‌کنیم:

• امضای دیجیتال (HMAC Signatures) – استاندارد طلایی:

معتبرترین روش در معماری وب‌هوک، استفاده از الگوریتم HMAC (Hash-based Message Authentication Code) است. روند کار به این شکل است که سرویس‌دهنده (مانند گیت‌هاب، استرایپ یا درگاه‌های بانکی) یک کلید مخفی (Secret Key) در اختیار شما قرار می‌دهد.

هنگام وقوع رویداد، سرویس‌دهنده بدنه درخواست (Body) را با استفاده از این کلید مخفی و الگوریتم‌هایی مانند SHA-256 هش کرده و نتیجه را در هدرِ (Header) درخواست ارسال می‌کند. سرور شما باید دقیقاً همان بدنه دریافتی را با کلید مخفی خود هش کرده و با مقدارِ هدر مقایسه کند. برابری این دو مقدار، اصالت درخواست را تضمین می‌کند.

• لیست سفید آی‌پی‌ها (IP Whitelisting):

به عنوان یک لایه امنیتی زیرساختی، می‌توانید در سطح فایروال یا وب‌سرور (مانند Nginx) تنظیماتی اعمال کنید تا Endpoint وب‌هوک شما فقط درخواست‌هایی را بپذیرد که از دامنه‌ی IPهای رسمی و اعلام‌شده‌ی سرویس‌دهنده (Provider) نشأت گرفته‌اند. با این کار، ترافیک نامعتبر و درخواست‌های فیک قبل از رسیدن به لایه اپلیکیشن (Application Layer) دراپ (Drop) می‌شوند.

• استفاده از توکن‌های احراز هویت (Bearer Tokens / Basic Auth):

در این پروتکل، یک توکن امنیتی ثابت (Static Token) یا اطلاعات Basic Auth در هدرِ ریکوئست قرار می‌گیرد. سرور گیرنده با بررسی هدر Authorization، تایید می‌کند که آیا ارسال‌کننده مجاز به فراخوانی این Endpoint هست یا خیر.

نکته حیاتی معماری: پیاده‌سازی تمام این پروتکل‌های امنیت تنها زمانی معنا پیدا می‌کند که بستر ارتباطی شما بر روی HTTPS (پروتکل TLS) پیکربندی شده باشد. راه‌اندازی وب‌هوک روی بستر HTTP بدون رمزنگاری، باعث می‌شود تمام داده‌های حساس و کلیدهای امنیتی در میانه راه قابل شنود (Man-in-the-Middle Attack) باشند.

جمع‌بندی

وب‌هوک یک جابه‌جایی جدی در معماری تبادل داده است. سیستم‌ها به جای پرس‌وجوی مداوم، به رویدادها واکنش نشان می‌دهند و همین موضوع باعث کاهش بار اضافی، افزایش سرعت واکنش و بهینه‌تر شدن مصرف منابع می‌شود. در پیاده‌سازی واقعی، ارزش وب‌هوک زمانی مشخص می‌شود که پای مقیاس بالا، تراکنش‌های حساس و یکپارچگی بین چند سرویس وسط باشد. در این نقطه، طراحی درست Endpoint، مدیریت خطا، و اعتبارسنجی امنیتی تعیین‌کننده کیفیت کل سیستم است.

امیدواریم که از این مطلب در کندو نهایت استفاده را برده باشید. بعلاوه اگر به موضوعاتی مشابه مانند آموزش پایتون و یا هر چیز دیگر‌ی مرتبط با فناوری، شبکه و کامپیوتر علاقه دارید، حتما به مقالات دیگر کندو هم سر بزنید.

سوالات متداول

• اگر سرور من در زمان ارسال وب‌هوک قطع (Down) باشد چه اتفاقی می‌افتد؟

اکثر سرویس‌دهنده‌های استاندارد (مثل درگاه‌های بانکی یا گیت‌هاب) دارای مکانیزم Retry هستند. اگر سرور شما کد وضعیت 200 OK را برنگرداند، آن‌ها ارسال وب‌هوک را در فواصل زمانی مشخص (مثلاً ۵ دقیقه، ۱ ساعت و…) تکرار می‌کنند. با این حال، همیشه باید یک مکانیزم Fallback (مانند فراخوانی یک API برای چک کردن وضعیت نهایی) در سیستم خود داشته باشید.

• چگونه وب‌هوک را روی سیستم لوکال (Localhost) تست کنم؟

از آنجایی که وب‌هوک نیاز به یک آدرس عمومی (Public URL) دارد، نمی‌توانید مستقیماً آن را روی localhost دریافت کنید. برای این کار باید از ابزارهایی مانند ngrok استفاده کنید که یک تونل امن ایجاد کرده و لوکال‌هاست شما را به اینترنت متصل می‌کند. برای مشاهده خام دیتای ارسالی (Payload) نیز ابزار Webhook.site بسیار کاربردی است.

• آیا وب‌هوک‌ها از نظر امنیتی قابل اعتماد هستند؟

بله، اما امنیت آن‌ها به پیاده‌سازی شما بستگی دارد. برای جلوگیری از حملات و درخواست‌های جعلی (Spoofing)، باید حتماً از پروتکل HTTPS استفاده کنید، آی‌پی‌های (IP) سرور فرستنده را در لیست سفید (Whitelist) قرار دهید و مهم‌تر از همه، امضای دیجیتال (HMAC) موجود در هدر (Header) درخواست را با کلید مخفی (Secret Key) خود اعتبارسنجی کنید.

• متد HTTP در وب‌هوک چیست؟

وب‌هوک‌ها تقریباً همیشه از متد POST استفاده می‌کنند، زیرا قرار است دیتا (Payload) حاوی اطلاعات رویداد رخ‌داده را در بدنه (Body) درخواست برای شما ارسال کنند.