آشنایی با درگاه API و ابزارهای آن

در این پست به بررسی مفهوم مدیریت API و درگاه API می‌پردازیم، چگونگی عملکرد درگاه API را بیان می‌کنیم، و تعدادی از ابزارهای ارائه‌دهنده درگاه API را معرفی می‌کنیم.

درگاه API چیست؟

درگاه API (API gateway) میان‌افزاری (middleware) است که بین یک نقطه انتهایی API (endpoint) و سرویس‌های backend قرار می‌گیرد و request های client را به سرویس مناسبی از یک برنامه انتقال می‌دهد. همچنین API gateway یک الگوی معماری است که در ابتدا برای پشتیبانی از میکروسرویس‌ها ایجاد شد.

تکامل معماری API

پیش از این، اپلیکیشن‌ها عمدتا با استفاده از رویکرد monolithic ساخته می‌شدند، یعنی همه‌ی اجزای نرم‌افزار به هم متصل بودند. از این رو client در زمان درخواست بازیابی داده‌ها، یک API callبرقرار می‌کرد. سپس ابزاری به نام load balancer(که در گذشته یک دستگاه سخت‌افزاری جدا بود) همه‌ی ترافیکی که بین نمونه‌های مختلف یک برنامه را دریافت می‌کرد را هدایت می‌کرد و پاسخ (response) را به client باز می‌گرداند. در این رویکرد بروزرسانی و پیاده‌سازی تکنولوژی‌های جدید سخت بود، به همین دلیل معماری monolithic با یک الگوی معماری جدید به نام میکروسرویس (microservices) جایگزین شد.

معماری میکروسرویس سرویس‌های مختلف را در سیستم شما از هم جدا می‌کند و آن‌ها را مستقل می‌سازد. برخلاف رویکرد monolithic، هر میکروسرویس نقطه انتهایی (endpoint) عمومی متفاوتی دارد، از این رو clientدرخواست‌ها (requests) را مستقیما به میکروسرویس خواسته شده ارسال می‌کند. برای اپلیکیشن‌های کوچک تر مسئله‌ای وجود ندارد، اما به محض این که یک سیستم در سطح سازمانی معماری میکروسرویس را اتخاذ کند، مشکلات متعددی به وجود خواهد آمد. در ادامه به بررسی تعدادی از این مشکلات می‌پردازیم.

تاخیر (Latency): برای انجام یک عملکرد ساده مانند ورود به اپلیکیشن، client باید چندین تماس (call) با میکروسرویس‌های مختلف برقرار کند. این موضوع باعث افزایش تعداد رفت و برگشت‌ها و درنتیجه زمان انتظار طولانی تر می‌شود.

امنیت (security): از آنجایی که هر میکروسرویس از طریق یک نقطه انتهایی عمومی در دسترس است، ریسک حمله بالاتری وجود دارد. در حالت ایده آل هر سرویس باید مجوز () داشته باشد اما پیاده سازی چنین چیزی بسیار هزینه‌بر و زمان‌بر است.

اتصال محکم (Tight coupling): در ارتباط مستقیم اپلیکیشن‌های client به شدت به میکروسرویس‌های داخلی متصل می‌شوند و بروزرسانی یا بازنشتگی آن‌ها در آینده، اپلیکیشن‌های client را نیز تحت تاثیر قرار می‌دهد.

چنین مسائلی را می‌توان با معرفی یک سطح واسط بین client و API حل کرد، یک درگاه API.

درگاه API تعادل بار (load balancing) را انجام می‌دهد، تدابیر امنیتی را فراهم می‌سازد و اتصال سست (loose coupling) را ایجاد می‌کند.

تصویر پایین 1) دسترسی به monolith از طریق یک API واحد، 2) دسترسی به میکروسرویس‌ها از طریق APIهای جداگانه، 3) استفاده از یک درگاه API واحد، و 4) دسترسی به گروهی از میکروسرویس‌ها از طریق چندین درگاه API، را نشان می‌دهد.

عملکرد های API gateway و مدیریت API

درگاه API عملکردهای کاملا فنی را انجام می‌دهد. مدیر API اصطلاح مشابهی است که معمولا معنای گسترده تری دارد. در اینجا چگونگی ارتباط بین درگاه API و مدیر API را توضیح می‌دهیم.

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

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

مدیرهای API تکامل یافته‌ی درگاه‌های APIهستند، زیرا اقتصاد API در حال رشد بود و کسب و کارها نیاز داشتند API‌هایشان را بازاریابی کنند و آن‌ها را به جریان درآمد دیگری تبدیل کنند. مدیر APIعملکردهایی مانند ایجاد مستندات، جمع‌آوری بازخوردها، و سازمان‌دهی یک کاتالوگ API کاربرپسند (user‑friendly) را برای کسب و کارها ممکن می‌سازد. به علاوه تجزیه و تحلیل داده‌های استفاده شده آن‌ها را به بینشی تبدیل می‌کند که به کسب و کارها کمک می‌کند یاد بگیرند که چگونه APIرا به عنوان یک محصول توسعه دهند.

درگاه API در نقش facade و الگوی Backend For Frontend (BFF)

الگوی معماری facade یک رابط واحد (single interface) را در مقابل یک سیستم پیچیده پیاده سازی می‌کند. این الگو قابلیت استفاده را بهبود می‌بخشد و اتصال سست (loose coupling) را ممکن می‌سازد. در واقع الگوی facade به شما این امکان را می‌دهد که مؤلفه‌های backend را، بدون آن که روی client اثر بگذارند، نگهداری کنید و تغییر دهید.

در عین حال، نقطه ورود واحد می‌تواند به سرعت تبدیل به گلوگاه (bottleneck) شود و نهایتا بار دیگر به شکل رویکرد monolithic درآید. اینجا از الگوی Backend For Frontend (BFF) استفاده می‌شود. در این الگو ممکن است چندین درگاه API به عنوان facade برای گروه‌های مختلف سرویس‌ها عمل کنند. به عبارت دیگر در این الگو اپلیکیشن‌ها می‌توانند بر اساس وظایف تجاری یا برنامه‌های client، چندین درگاه API داشته باشند (مانند درگاه‌های جدا برای وب و برنامه‌های موبایل).

الگوی Backend For Frontend برای درگاه API

مسیریابی requestها در درگاه API

برای درک بهتر مفهوم مسیریابی درخواست‌ها در درگاه API به یک مثال در دنیای واقعی توجه کنید. فرض کنید در یک هتل هستید و از اتاق خود با مسئول پذیرش تماس می‌گیرید و یک سینی صبحانه یا استفاده از سرویس خشک‌شویی را درخواست می‌کنید، پذیرش کسی نیست که سرویس را به شما ارائه دهد، بلکه درخواست شما را به شخص مناسب می‌رساند. این کار هم برای راحتی شما انجام می‌شود و هم برای راحتی کارکنان، شما دیگر در هتل به دنبال آشپزخانه یا اتاق رختشویی نمی‌روید و کارکنان مجبور نیستند علاوه بر شغل اصلی خود با خدمات مشتری سروکار داشته باشند. درگاه API به همین ترتیب کار می‌کند، و این رویکرد پروکسی معکوس (reverse proxy) نامیده می‌شود. برخلاف پروکسی رو به جلو (forward proxy) که منشاء clientرا با بازیابی داده‌ها از شبکه عمومی از طرف آن‌ها پنهان می‌کند، درگاه منشاء server را پنهان می‌کند و داده‌های داخلی را برای مشتری بازیابی می‌کند. درگاه API به عنوان یک نقطه انتهایی واحد (که اپلیکیشن‌های client از آن استفاده می‌کنند) عمل می‌کند و سپس همه‌ی requestها را به سرویس‌های داخلی هدایت می‌کند. در عین حال، درگاه API می‌تواند responseها را از چندین سرویس جمع‌اوری کرده و آن‌ها را به عنوان یک پاسخ بفرستد، درنتیجه تعداد تماس‌ها (call) کاهش می‌یابد.

ترجمه پروتکل‌های مختلف

اکثر APIهای خارجی responseهایی در قالب پیام‌های REST ارائه می‌دهند، اما سرویس‌های داخلی شما ممکن است وابسته به سایر فرمت‌ها باشند. به عنوان مثال سیستم‌های قدیمی تنها از پروتکل SOAP پشتیبانی می‌کنند، یا شما می‌خواهید از مزایای gPRC بهره‌مند شوید. درگاه API می‌تواند تماس‌های REST را به پروتکل‌های سازگار ترجمه کند.

ابزارهای ارائه دهنده‌ی API gateway

‏Kong Gateway

ابزار Kong انواع عملکردهای مدیریت API و درگاه API را فراهم می‌سازد و دو گزینه برای آن وجود دارد: یک محصول منبع‌باز (open‑source) و یک محصول دارای مجوز (licensed) با چند ویژگی اضافی. از نظر استقرار (deployment) نیز چند منظوره است، که یکی از آن‌ها container های از پیش ساخته شده‌ی Docker می‌باشد. نسخه open‑source در محل (On-premise) اجرا می‌شود اما نسخه‌ی سازمانی از اجرای ابری ترکیبی (hybrid cloud) نیز پشتیبانی می‌کند. Kongبخاطر pluginهای فراوانش، چه رسمی و چه توسعه یافته توسط عموم، معروف شده است، که به شما این امکان را می‌دهد تا در صورت نیاز درگاه API خود را به یک پلتفرم مدیریت API کامل تبدیل کنید. با این حال، Kongبرای مدیریت برنامه‌های قدیمی انتخاب قابل اطمینانی نمی‌باشد، چرا که نمی‌تواند تماس (call) ها را به فرمت‌های SOAP یا XML تبدیل کند. این ابزار برای اپلیکیشن‌های مبتنی بر میکروسرویس مدرن مناسب است.

‏AWS API Gateway

اگر در حال ساخت یک معماری server‑less با AWS Lambda هستید، درگاه AWS APIبهترین انتخاب برای شماست. این ابزار cloud‑only است و کاربران AWS می‌توانند تنها با چند کلیک آن را ادغام کنند. سطح رایگان این ابزار با یک میلیون API callبه پایان می‌رسد، بنابراین امتحان کردن آن ضرری ندارد، به خصوص که مجموعه ویژگی‌های آن با نسخه سازمانی Kong قابل مقایسه است.

‏Tyk Gateway

درگاه Tyk، open-source می‌باشد و با وجود ویژگی‌هایی در سطح سازمانی رایگان است. ادغام آسان از سایر ویژگی‌های مثبت این نرم‌افزار است، به این صورت که شما می‌تواند پلاگین‌هایی به زبان Python، JavaScript، Go، و سایر زبان‌ها بنویسید و یا از پلاگین‌های ایجاد شده توسط عموم استفاده کنید. در Tyk هر پروتکلی پذیرفته شده و قابل تبدیل است: REST، SOAP، gPRC، GraphQL، و TCP.

‏KrakenD‏

‏‏KrakenD یک درگاه API open-source است و برای انواع استقرار: در محل (on‑premises)، ابری (cloud) و ترکیبی (hybrid)، در دسترس است. از ویژگی‌های منحصر به فرد آن روشی اعلانی برای ایجاد نقاط انتهایی است که امکان استفاده از آن را بدون هیچ گونه برنامه نویسی فراهم می‌کند. یک سطح سازمانی با تعدادی ویژگی اضافی مانند تولید مشخصات OpenAPIبرای آن وجود دارد، اما استفاده از ویژگی‌های استاندارد برای همه رایگان و نامحدود است. شما می‌توانید KrakenD را با استفاده از Go و Lua توسعه دهید.

‏Gloo Edge ‏‏‏

این ابزار مبتنی بر پروکسی Envoy می‌باشد. پروکسی Envoy محبوب ترین پروکسی برای Kubernetes است. ابزار Gloo یک نسخه open‑source و یک نسخه سازمانی دارد. هر دو نسخه از عملکردهای server-less و مسیریابی برای gRPC پشتیبانی می‌کنند.

‏Apigee‏

‏‏Apigee پلتفرمی برای توسعه و مدیریت API ها می‌باشد. این پلتفرم به زبان جاوا نوشته شده است و open-source نیست. پلتفرم Apigee در ابتدا به عنوان یک برنامه XML/SOA شروع به کار کرد، اما به فضای مدیریت API برگشت. Apigee برای تبدیل برنامه‌های قدیمی monolith به API های قابل استفاده برای اشخاص ثالت طراحی شده است و تمرکز کمتری روی میکروسرویس‌ها و API های داخلی دارد. این پلتفرم در سال 2016 توسط گوگل خریداری شد.

شرکت‌های ایرانی فعال در زمینه مدیریت API

شرکت وصل

شرکت وصل پلتفرم مدیریت API سورنا را ارائه می‌دهد. اسپارا در زمینه گذرگاه سرویس سازمانی (ESB) ، آریو در زمینه Backend-as-a-Service (BaaS)، و نوین در زمینه پلتفرم تحویل سرویس VAS، از محصولات دیگر این شرکت می‌باشند.

شرکت ابر درسا

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

شرکت پلکتو

شرکت دانش بنیان پلکتو پلتفرم یکپارچه سازی و مدیریت وب سرویس می‌باشد و خدماتی مانند گذرگاه سرویس سازمانی (ESB) و مدیریت API ارائه می‌دهد.