مقایسه API با WebSocket و WebHook : کدام یک را انتخاب کنیم؟

آفلاین
user-avatar
عرفان حشمتی
28 فروردین 1400, خواندن در 7 دقیقه

در هر برنامه‌ای که استفاده می‌کنیم، به یک مکانیسم قابل اتکا برای برقراری ارتباط بین اجزای آن نیاز داریم. به عنوان مثال در برنامه‌های وب، باید بین مرورگر و سرور ارتباط برقرار کنیم. گاهی اوقات سرور نیاز به ارسال پیام به مرورگر دارد. علاوه بر این مواردی وجود دارد که بک-اند به سرویس دیگری وابسته است که پیاده سازی آن مدت زمان زیادی طول می‌کشد. اینجاست که APIها، WebSocketها و WebHookها وارد عمل می‌شوند. این روش‌ها مکانیزم بی عیب و نقصی را برای برقراری ارتباط و همگام سازی داده‌ها در قسمت‌های مختلف برنامه فراهم می‌کنند.

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

API ها- رابط و قراردادی را برای استفاده کنندگان فراهم می‌کنند.

API یا Application Programming Interface قراردادی است بین استفاده کننده و ارائه دهنده خدمات که برنامه را معمولا از طریق HTTP در معرض تعامل قرار می‌دهد.

این برای سناریوهایی مانند عملیات CRUD اولیه از وب، تلفن همراه یا حتی برای ادغام سرویس به سرویس فوق العاده خوب عمل می‌کند و بیشتر ارتباطات با استفاده از JSON یا XML به عنوان قالب انتقال داده اتفاق می‌افتد.

بیایید یک سناریو را در نظر بگیریم که کاربران در یک وب سایت تجارت الکترونیکی محصولات را جستجو می‌کنند. هنگامی که کاربر با استفاده از یک جستجو آنچه را که می‌خواهد درخواست می‌کند، ظرف چند ثانیه پاسخ می‌گیرد. روند یک API به همین سادگی است.

نحوه فراخوانی API در یک برنامه وب

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

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

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

اما نظرسنجی کارآمد نیست و ما روش‌های بهتری مانند WebSocket را برای حل چنین چالش‌هایی داریم.

نکته: کامپوننت‌های قابل استفاده مجدد خود را با استفاده از Bit (Github)بین پروژه‌ها به اشتراک بگذارید.

Bit اشتراک گذاری، مستند سازی و استفاده مجدد از کامپوننت‌های مستقل بین پروژه‌ها را ساده می‌کند. همچنین از آن برای به حداکثر رساندن استفاده مجدد از کد، حفظ یک طراحی ثابت، تحویل سریع و ساخت برنامه‌های مقیاس پذیر استفاده می‌شود.

به علاوه از Node ،TypeScript ،React ،Vue ، Angular و موارد دیگر پشتیبانی می‌کند.

مثال: بررسی کامپوننت‌های ری‌اکت قابل استفاده مجدد که در Bit.dev به اشتراک گذاشته شده است

WebSocket ها- هنگامی که به ارتباطات بی درنگ (real-time) نیاز دارید

WebSocket ها با برقراری ارتباط مداوم و دو طرفه بین مصرف کننده و ارائه دهنده خدمات این چالش را برطرف می‌کنند.

داشتن یک کانال ارتباطی دو طرفه به ارائه دهندگان خدمات این امکان را می‌دهد تا در هر زمان پیام ارسال کنند. از آنجا که همه مرورگرهای مدرن از WebSocket ها پشتیبانی می‌کنند، بنابراین بهترین راه حل برای برنامه‌های وب real-time هستند.

نحوه عملکرد WebSocket

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

به عنوان مثال اگر همان سناریوی تولید گزارش را در نظر بگیریم، استفاده از WebSocket ها ممکن است یک گزینه عالی برای وب باشد. با این حال می‌تواند بهترین گزینه برای تلفن همراه نیز در نظر گرفته شود. جایی که لازم باشد از ویژگی‌هایی مانند اعلان‌ها استفاده کنیم. توجه داشته باشید که اگر بک-اند ما برای تهیه گزارش به سرویس خارجی وابسته باشد، WebSocket گزینه مناسبی برای ارتباط با سرویس خارجی نیست.

در اینجاست که ما به مکانیزمی مانند WebHook نیاز داریم.

نحوه اتصال مصرف کننده، بک-اند و سرویس خارجی با استفاده از WebSocket  ها وWebHook  ها 

WebHook ها- یک راه حل عالی برای فراخوانی بک-اند

WebHook با ارائه یک مکانیزم قطع شده برای دریافت پاسخ از طرف ارائه دهنده خدمات، راه حلی برای مسئله overkilling در WebSocket ارائه می‌دهد.

اگر جنبه فنی را در نظر بگیریم، کلاینت WebHook (URL برگشتی) را در ارائه دهنده خدمات ثبت می‌کند و این URL به عنوان محلی برای دریافت داده از WebHook تلقی می‌شود.

در بیشتر موارد این URL به سرور دیگری تعلق دارد و WebHook بیشتر برای برقراری ارتباط بین سرورها یا پردازش‌های بک-اند مورد استفاده قرار می‌گیرد.

اگر در روند کار عمیقتر فرو برویم، می‌توانیم این فرایند را به چهار بخش تقسیم کنیم.

نحوه کار WebHook

  • راه اندازی رویداد: این رویدادی است که شما برای اجرای WebHook مشخص کردید. هر بار که رویداد رخ می‌دهد، WebHook وظیفه خود را انجام می‌دهد.
  • ارائه دهنده WebHook را ایجاد می‌کند و درخواست POST را می‌فرستد: ارائه دهنده WebHook وظیفه نظارت بر رویداد و ایجاد WebHook را دارد. پس از شروع رویداد، ارائه دهنده درخواست POST HTTP را به برنامه شخص ثالث ارسال می‌کند.
  • برنامه شخص ثالث داده دریافت می‌کند: برنامه شخص ثالث داده‌ها را از URL یا شنونده‌ای که هنگام ثبت نام در اختیار ارائه دهنده قرار می‌دهید، دریافت می‌کند.
  • اقدام مشخص شده در برنامه شخص ثالث: هنگامی که برنامه درخواست POST را دریافت کرد، توسعه دهندگان می‌توانند از داده‌ها برای هر کاری که می‌خواهند استفاده کنند.

در سطوح بالاتر احساس خواهید کرد که کاملا برعکس روند API است و به همین دلیل بیشتر افراد از WebHook به عنوان API معکوس یاد می‌کنند.

جمع بندی

همانطور که در ابتدا ذکر کردیم WebHook  , WebSocket و API ارتباطات را آسان می‌کنند و موارد استفاده مختلفی دارند.

API ها بهترین گزینه برای برنامه‌هایی هستند که فقط به عملیات CRUD اساسی و پاسخ همزمان نیاز دارد. همچنین از API ها می‌توان در وب و برنامه‌های تلفن همراه و خدمات ترکیبی استفاده کرد.

اما اگر برنامه وب شما به برقراری ارتباط بیدرنگ در بک-اند نیاز دارد، باید WebSocket را انتخاب کنید. این به شما امکان می‌دهد یک کانال ارتباطی دو طرفه بین مرورگر و بک-اند خود ایجاد کنید.

با این حال WebHook با API و WebSocket تفاوت اندکی دارد و بیشتر شبیه API معکوس عمل می‌کند. هنگامی که مصرف کننده URL WebHook را در ارائه دهنده خدمات ثبت کرد، دومی می‌تواند در صورت لزوم WebHook را فراخوانی کند.

فکر می‌کنم اکنون موارد مختلف استفاده از این روش‌های ارتباطی را درک کرده‌اید و اگر نظری دارید، لطفا در بخش زیر به اشتراک بگذارید.

منبع

چه امتیازی به این مقاله می دید؟
خیلی بد
بد
متوسط
خوب
عالی

دیدگاه‌ها و پرسش‌ها

برای ارسال دیدگاه لازم است، ابتدا وارد سایت شوید.

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

آفلاین
user-avatar
عرفان حشمتی @heshmati74
مهندس معماری سیستم های کامپیوتری، طراح و توسعه دهنده وب سایت
دنبال کردن

گفتگو‌ برنامه نویسان

بخشی برای حل مشکلات برنامه‌نویسی و مباحث پیرامون آن وارد شو