اگر دستی در برنامه نویسی داشته باشید،احتمالا از API ها برای برقراری ارتباط بین دو نرم افزار متفاوت استفاده کرده‌اید و می‌دانید که برای تبادل داده بین Service و Client نیز از API استفاده می‌شود. اگر بخواهیم نمودی از API را در دنیای واقعی مثال بزنیم می توانیم یک رستوران را در نظر بگیریم که شما برای خوردن غذا به آن مراجعه می کنید. به عنوان مشتری(Client) هیچ وقت برای سفارش غذا وارد آشپزخانه(Service) نمی‌شوید و با سر آشپز درباره‌ی جزئیات مواد غذایی و نحوه‌ی طبخ آن صحبت نمی کنید؛بلکه غذایی(Request)که مدنظر دارید به گارسون(API) سفارش می دهید و گارسون سفارش شما را به آشپزخانه(Service) می‌رساند و در نهایت غذای شما(Response) را به دست شما(Client) می‌رساند و این گونه شما نیازی به صحبت مستقیم با سرآشپز و آگاهی از نحوه‌ی پخت غذا و مواد اولیه آن ندارید و و فقط با گارسون در ارتباط هستید.
API ها در واقع سطح انتزاعی را برای برنامه Client به وجود می‌آورند تا با جزئیات Service درگیر نشود و فقط پاسخ درخواستش را دریافت کند و داده‌های مورد نیازش را با ساختار مناسب از طریق API دریافت کند.
زمانی که شروع به پیاده‌سازی برنامه‌ا‌ی کوچک و ساده برای یک فروشگاه آنلاین را می کنیم،احتمالا از معماری Monolithic استفاده میکنیم؛بنابراین Client فقط با یک API Call می تواند تمامی داده‌های مورد نیازش را از Service بگیرد.مثلا می‌تواند فقط با درخواست GET(api.myshop.com/product/48) تمامی داده‌های مربوط به صفحه‌ی جزئیات کالا با آی دی 48 را بگیرد. این سبک برنامه‌نویسی با وجودی که آسان‌تر است و نیاز به دانش بالایی ندارد اما با گذشت زمان و افزایش تعداد کاربران تعداد درخواست‌هایی که به API زده می شود بالا می‌رود و ممکن است سرور Down شود.درصورتی که بخواهیم همچنان تمام سرویس‌های برنامه را با یک API Call به کار بگیریم توسعه و نگه‌داری آن به مراتب سخت‌تر می‌شود؛همچنین به دلیل یک دست بودن پروژه با ازکار افتادن بخشی از آن کل سیستم مختل خواهد شد.بنابراین معماری Monolithic برای پروژه‌های بزرگ با تعداد درخواست‌های زیاد مناسب نیست؛به همین دلیل پروژه را به قسمت‌‌های مختلفی تقسیم میکنیم که هر قسمت به منحصرا یک وظیفه داشته باشد(Single Responsibility) که به هر یک از این قسمت‌ها یک Microservice گفته می شود و این سبک معماری،معماری Microservice خوانده می شود.
سرویس‌های مختلفی که برای فروشگاه آنلاین می‌توانیم در نظر بگیریم شامل سرویس اطلاعات محصول،سرویس تامین کنندگان،سرویس کاربران،سرویس جستجو ، سرویس نظرات ، سرویس سبد خرید و سرویس محصولات پیشنهادی می تواند باشد که هر یک API مخصوص به خود را دارند؛بنابراین برنامه‌ي سمت Client برای دریافت تمامی داده‌های صفحه جزئیات محصول یعنی اطلاعات محصول،تامین کنندگان،نظرات و ... باید چند Request را برای API سرویس‌های مختلف بفرستد تا داده‌های مورد نیازش را به دست بیاورد.
این روش بسیار روش بدیهی و ساده‌ای است اما مشکلات فراوانی را در پی خواهد داشت.اولین مشکلی که احتمالا متوجه آن شده‌اید تعداد زیاد درخواست برای داده‌های فقط یک صفحه آن هم توسط فقط یک Client است و می دانیم که این برنامه تعداد صفحات زیادی دارد که هر یک با این روش نیاز به درخواست از چندین سرویس برای دریافت داده‌هایشان هستند.همچنین تعداد زیادی از کاربران با Client های متفاوتی مانند Mobile App،Web App و... با فروشگاه آنلاین ما در تعامل خواهند بود.
مشکل دیگری که در این روش وجود دارد پایین بودن سطح امنیت است چرا که هر یک از سرویس‌های ما یک Rest API برای خودشان دارندکه نمی‌خواهیم تمامی آنها برای عموم قابل دسترس باشند.
یکی دیگر از مشکلات اساسی این روش این است که به دلیل ویژگی تغییر پذیری نرم افزار در طی زمان متوجه اشتباهاتمان در طراحی سیستم بشویم و نیاز داشته باشیم که دو یا چند سرویس را با ادغام کنیم و یا سرویس دیگری را به آنها اضافه کنیم.در این صورت نیاز داریم Request های مربوطه را سمت Client تغییر دهیم که ریسک بالایی دارد.
به خاطر حل تمامی این مشکلات و مشکلات دیگری که در ادامه به آنها خواهیم پرداخت،نیاز به یک واسط کاربری میان Clientها و Service ها داریم.
API Gateway یک واسط کاربری است که میان Client و Service قرار میگیرد و سطح انتزاعی را بین آنها ایجاد می کند.با وجود API Gateway دیگر نیازی نیست که Client برای دریافت داده‌های مورد نیازی با چندین سرویس تعامل کند. درخواست خود را به API Gateway ارسال میکند و این API Gateway هست که تشخیص می‌دهد برای پاسخ به درخواست Clientبه کدام سرویس‌ها باید درخواست بدهد و سرویس‌ها پاسخ خود را به API Gateway ارسال می کنند و API Gateway پاسخ نهایی را برای Client ارسال میکند.
بنابراین زمانی که تعداد درخواست‌ها بالا می رود زمان پاسخ به Client ها به شکل چشمگیری کاهش پیدا نمی‌کند و هر یک ازClientها طی مدت زمان مطلوبی می‌توانند داده‌های مورد نیازشان را دریافت کنند.
همانطور که در تصویر مشخص است هریک از سرویس‌ها فقط با API Gateway در ارتباط هستند و بنابراین نیازی به این نیست که REST API های هر یک از سرویس‌ها به صورت عمومی در دسترس قرار بگیرد و بنابراین وجود API تا حد قابل قبولی امنیت سرویس‌ها را تصمین میکند.
همچینین گفتیم که وجود API Gateway باعث به وجود آمدند سطح انتزاعی میان Client و Service ها می‌شود و Client ها نیازی به دانستن تعداد سرویس‌های موجود و این که هر کدام مسئول چه بخشی از منطق نرم‌افزاری هستند،ندارد؛بنابراین هنگامی که نیاز به Refactor کردن سرویس‌ها و تغییر طراحی سیستم داریم،نیازی نیست تغییری در نحوه‌ی درخواست Client دهیم و بنابراین به راحتی می توانیم در هر مرحله‌ای از توسعه در سرویس‌هایمان تغییر ایجاد کنیم.
مزایای دیگر API Gateway ها
علاوه بر مواردی که گفته شد،API Gateway ها می توانند مزایای دیگری را هم برای ما فراهم کنند که باعث افزایش سرعت و بهره‌وری سیستم نرم افزاری شود.
· مواردی مانند Authorization و Authentication را می توان در تنظیمات API Gateway پیاده سازی کرد؛چرا که برای تمامی درخواست‌های Client ها نیاز داریم دسترسی کاربر به صفحات درخواستی و همچنین عملیات مورد نظر را بررسی کنیم و سپس پاسخ مناسب را به Client برگردانیم.البته می توانیم در تک تک سرویس‌ها Authentication و Authorization را پیاده سازی کنیم اما در این حالت سیستم کند تر می شود چرا که برای یک درخواست چندین سرویس باید یک کار یکسان را انجام دهند و دروصورتی که بخواهیم قواعد Authentication و Authorization را تغییر دهیم باید در تک تک سرویس‌ها این کار را انجام دهیم ؛بنابراین مسئولیت Authentication و Authorization را می توانیم به عهده‌ی API Gateway بگذاریم.
· API Gateway ها برای Monitoring و بررسی میزان موفقیت درخواست‌ها در شرایط متفاوت، نمودار‌های مختلفی را از تعداد درخواست‌ها و نرخ پاسخ دهی به آنها را در اختیار توسعه دهندگان نرم افزار قرار می دهد از این رو توسعه دهندگان می‌توانند به سرعت متوجه مشکلات موجود شوند و برای رفع آنها اقدام کنند.
· خیلی اوقات پیش می آید که بخواهیم دسترسی به سرویس‌هایمان را از طریق IP های خاصی کاهش دهیم و یا تعداد درخواست‌هایی که در طی مدت زمان مشخصی به سرویس‌هایمان می رسد را محدود کنیم.در تنظیمات API Gateway توانیم مشخص کنیم که چه IP Range ای می‌تواند به سرویس‌های ما دسترسی داشته باشد یا مثلا در هر ثانیه چند درخواست می‌توانند به سرویس‌های ما وارد شوند.
· یکی دیگر از موارد کاربردی در استفاده از API Gateway ها عدم نیاز به یکسان بودن پروتکل‌های ارتباطی میان Client و Service است.برای مثال Client می‌تواند با پروتکل HTTPS درخواست‌های خود را برای API Gateway ها بفرستد اما API Gateway با توجه به پروتکل مورد نیاز هر سرویس آن درخواست را برای سرویس‌ها میفرستد که لزوما HTTPS نیست.
و موارد دیگری از جمله Response Caching ،Load Balancing و ... را می‌توان با توجه به نیاز‌های موجود در تنظیمات API Gateway ها تعریف کرد.
ابزار‌های متن باز موجود برای API Gateway ها
1. HAProxy(High Availability Proxy) یک نرم افزار سرور متن باز برای Proxy و Load Balancing است که در لایه های Application و Network دسترسی بالا(High Availability) ،بهبود سرعت و کارایی را از طریق توزیع بار کاری بر روی سرور‌های متفاوت فراهم می کند. HAProxy بر روی سیستم عامل‌های Linux،FreeBSD و Solaris اجرا می‌شود. از جمله امکاناتی که می‌تواند ارائه دهد می توان به موارد زیر اشاره کرد.
URI/URL based load balancing: Yes
Logging: Yes
Protocols: Application and network layers
SSL termination: Yes
Session stickiness: Yes
Global/geo server load balancing: No
Scalability: Manual/predefined rules
Algorithms: Network layer
Installation and maintenance: Extensive
Single point of failure: Likely (if on premises)
Additional Features: No
2. NGINX نیز یکی دیگر از ابزار‌های متن باز است که خدماتی چون ReverseProxy،HTTP Load Balancer و Email Proxy برای IMAP،POP3 و SMTP ارائه می کند.NGINX یک معماری رویداد محور و ناهمگام را برای مدیریت کردن تعداد بالای ارتباطاتی است که به وب سرور ارسال می‌شوند.این ویژگی باعث شده است که NGINX به یکی از قابل اعتماد‌ترین سرور‌ها تبدیل شود.NGINX تقریبا تمامی امکانات مورد نیاز برای یک API Gateway را ارائه می‌دهد.
· شرکت وصل:این شرکت با ارائه‌ی پلتفرم مدیریت API به توسعه دهندگان جهت طراحی و پیاده‌سازی برنامه‌های مرتبط با سامانه‌های داخلی سازمان/سرویس دهنده،کمک میکند.از آن‌جایی که API ها در تکنولوژی‌های مختلفی نظیر اینترنت اشیاء،رایانش ابری و داده‌های حجیم نقش کلیدی را ایفا می‌کنند،این پلتفرم پایداری،امنیت و پشتیبانی ویژه‌ای را ارائه میکند تا هر شخص حقیقی و حقوقی بتواند با اطمینان ازآن استفاده کند.از جمله خدماتی که این شرکت ارائه می کند شامل:
1. مدیریت چرخه‌ی API ها با یک پلتفرم واحد:پلتفرم مدیریت API سورنا با نظارت، تجزیه و تحلیل داده‌ها، کنترل دسترسی‌ها و محافظت از اطلاعات حساس شما با سیاستهای امنیتی خود موفقیت شما را تظمین میکند و به شما کمک میکند در نبرد با متجاوزان دنیای دیجیتال پیروز باشید.
2. مانیتورینگ قدرتمند: بخش مانیتورینگ سورنا با ارائه تحلیل‌های دقیق و کاربردی به شما کمک میکند تا بتوانید هر روز عملکرد سیستم‌هایتان را افزایش و از وضعیت پاسخگویی آنها آمار و گزارشات دقیقی در اختیار داشته باشید.سیستم هشدارمتنی سورنا به کاربران این امکان رامی‌دهد تا در کوتاه ترین زمان ممکن مشکلات خود را شناسایی کنند و با صرف کمترین هزینه و کوتاهترین زمان آن مشکل را برطرف نمایند.
3. امنیت و اعتماد: با توجه به اینکه این مولفه در جلوی سرویس اصلی (سرویس ارائه دهنده API) قرار میگیرد، در صورتی که به خوبی پیکربندی شود می‌تواند به عنوان یک سد و لایه حفاظتی عمل نموده و در افزایش امنیت ارائه دهندگان API موثر باشد.سیستم خود را برای مقابله با هکرها، ربات‌ها و رفتارهای مشکوک آماده کنید. با آرامش و خیالی آسوده به ارائه خدمات خود بپردازید.
4.راه‌حل برای اینترنت اشیاء:امروزه اینترنت اشیا و کاربردهای آن در حال فراگیر شدن است. اما انتخاب پلتفرم مناسب چالش بسیاری از سازمان ها و مدیران شهری است. شما با مدیریت سرویس سورنا می‌توانید تمامی خدمات در حوزه IOT را در پنل مدیریت اضافه کنید و با توجه به نیاز کاربرانتان آنها را ارائه نمایید.
· شرکت ابر درسا:این شرکت سرویس API Gateway ابری را برای میزبانی API ها ارائه می‌کندکه تعداد زیادی از توابع مدیریت چرخه زندگی را برای کمک به ایجاد معماری سیستم API محور ارائه می دهد.این توابع شامل طراحی API،توسعه،آزمایش،انتشار،فروش،O&M و نظارت،امنیت و عدم انتشار است.ازجمله خدماتی که این شرکت ارائه می کند شامل:
1. از محیط های ناهمگن شبکه پشتیبانی می کند: سرویس Api Gateway ابری می تواند API های سیستم های تجاری شما را مدیریت کند، صرف نظر از اینکه سیستم های تجاری شما در ابر درسا ، مراکز داده محلی یا ابرهای شخص ثالث مستقر شده اند یا خیر.
2. ساخت انواع معماری فنی:معماری بدون سرور ترکیبی از Function Compute و API Gateway به توسعه دهندگان امکان می دهد تا کد را کشف کرده و به سرعت خدمات کم هزینه، بسیار در دسترس و مقیاس پذیر در
زمان واقعی را ایجاد کنند. این معماری توسعه مشاغل مرتبط با دستگاه های تلفن همراه، برنامه های وب، اینترنت اشیا (IoT) بازار ابر را تسهیل می کند. این معماری امکانات توسعه تجارت و
مرزهای تجاری را گسترش می دهد. انعطاف پذیری ترکیبات محصول بهبود یافته است.
3. معماری میکروسرویس:سرویس Api Gateway ابری به عنوان یک سرویس ابری بالغ عمل می کند که اجازه دسترسی به خوشه هایبرنامه Kubernetes را می دهد. این به طور قابل توجهی قابلیت های سرویس خوشه های برنامه Kubernetes را بهبود می بخشد. این معماری به عنوان معماری استاندارد برای برنامه های کاربردی اینترنت در مقیاس بزرگ عمل می کند.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
https://www.youtube.com/watch?v=hWRRdICvMNs
https://www.youtube.com/watch?v=1vjOv_f9L8I
https://www.youtube.com/watch?v=vHQqQBYJtLI&t=644s
https://www.youtube.com/watch?v=8WuVBbXsHzg
https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do
