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

پیشنهاد می‌کنیم اگر با این مفهوم آشنا نیستید، یادداشت «API چیست؟» و «کاربرد API چیست؟» را هم بخوانید.

انواع API از نظر سطح دسترسی

منظور از API در واقع یکی از زیردسته‌های آن به نام  Web API است. ‌Web APIها نوعی از API هستند که می‌توان از پروتکل HTTP (مخفف عبارت Hypertext Transfer Protocol) به آن‌ها دسترسی پیدا کرد. پروتکل HTTP برای دریافت و نمایش اطلاعات صفحات وب مورد استفاده قرار می‌گیرد. ما می‌توانیم APIها را بر اساس سطح دسترسی و مخاطبین هدف دسته‌بندی کنیم. چهار نوع کلی API وجود دارد:

• APIهای عمومی
• APIهای مشارکتی
• APIهای داخلی
• APIهای ترکیبی

APIهای عمومی

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

توسعه API‌های عمومی مزایای زیادی برای یک کسب‌و‌کار دارد که مهم‌ترین آن دسترسی آزاد به اطلاعات است. به این ترتیب کسب‌و‌کارها و توسعه‌دهنده‌ها به استفاده از API در سرویس یا اپلیکیشن خود ترغیب شده و ارزش API و آن اپلیکیشن افزایش پیدا می‌کند. سطح پایین احراز هویت و سهولت در استفاده نیز باعث می‌شود تا کسب‌و‌کارها بتوانند از داده‌های ارائه‌شده توسط APIهای عمومی با انعطاف بیشتری بهره ببرند.

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

APIهای مشارکتی

این نوع از انواع API ها تنها در اختیار کسب‌و‌کارهایی قرار می‌گیرد که با ارائه‌دهنده API رابطه تجاری دارند و یا برای استفاده از API قرارداد امضاء می‌کنند. سطح امنیت این APIها از APIهای عمومی بالاتر بوده و تنها سیستم‌های دارای مجوز به آن دسترسی دارند. کسب‌و‌کارها به دو دلیل از APIهای مشارکتی استفاده می‌کنند:

• کنترل افرادی که به API دسترسی دارند

• کنترل منابع و داده‌ها

برای مثال پلتفرم پینترست یک فرم درخواست دارد که متقاضین API باید در آن جزییات نحوه استفاده از API را شرح دهند. 

APIهای داخلی

APIهای داخلی (یا APIهای شخصی) بر خلاف دو نوع قبلی برای استفاده کسب‌و‌کارها و اشخاص ثالث طراحی نشده‌اند. این APIها تنها برای استفاده درون سازمان‌ها و شرکت‌ها طراحی می‌شوند و وظیفه آن‌ها تسهیل تبادل داده بین تیم‌ها و قسمت‌های مختلف شرکت است. APIهای داخلی به دلیل عدم مستندسازی به وسیله نرم‌افزارهای عمومی مستندسازی (یا عدم مستندسازی در کل) از دید عموم پنهان هستند. 

ویژگی‌های APIها نظیر امنیت، بهینه بودن، مقیاس‌پذیری و قابلیت رهگیری آن را به گزینه‌ای مناسب برای تبادل اطلاعات درون سازمان‌ها تبدیل می‌کند. 

APIهای ترکیبی

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

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

انواع معماری API ها

یک راه دیگر برای دسته‌بندی APIها، بر اساس ساختار معماری است. معماری یک API شامل قوانین و دستورالعمل‌هایی است که نشان می دهد یک API چه اطلاعاتی را و چگونه می‌تواند به اشتراک بگذارد. سه نوع REST، SOAP و RPC محبوب‌ترین‌ترین معماری‌های API هستند که در ادامه آن‌ها را توضیح می‌دهیم. 

معماری REST

امروزه طیف گسترده‌ای از APIها با استفاده از معماری REST توسعه پیدا می‌کنند. معماری REST (مخفف عبارت Representational State Transfer) یک دسته از قوانین برای ساخت یک API مقیاس‌پذیر، سبک و آسان را در اختیار توسعه‌دهنده‌ها قرار می‌دهد.

قواعد توسعه REST API

شش قاعده زیر ویژگی‌های لازم برای توسعه یک REST API را شرح می‌دهد

رابط کاربری یکپارچه

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

تعیین ریسورس‌ها

رابط کاربری باید هر ریسورس دخیل در تعاملات بین سرور و کلاینت را به طور جداگانه تشخیص دهد.

تغییر ریسورس‌ها از طریق نماینده‌ها

ریسور‌س‌ها باید نماینده‌های یکپارچه در پاسخ سرور داشته باشند. استفاده‌کنندگان API باید از این نماینده‌ها برای تغییر وضعیت ریسورس‌ها در سرور استفاده کنند.

پیام‌های شفاف

هر نماینده ریسورس باید اطلاعات کافی برای نحوه پردازش پیام را داشته باشد. همچنین این نماینده باید اطلاعات اعمالی که کلاینت می‌تواند روی ریسورس اجرا کند را داشته باشد.

استفاده از هایپرمدیا برای تغییر وضعیت اپلیکیشن

کلاینت تنها باید URI اپلیکیشن را اجرا کند. اپلیکیشن کلاینت باید تمام تعاملات و ریسورس‌های دیگر را با استفاده از هایپرلینک دریافت و اجرا کند.

کلاینت – سرور

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

بدون وضعیت

بدون وضعیت بودن یعنی هر درخواست از سمت کلاینت به سرور باید حاوی تمام اطلاعات لازم برای اجرای درخواست باشد. سرور نمی‌تواند از اطلاعات قبلی ذخیره‌شده استفاده کند. 

قابل کش شدن

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

سیستم لایه‌ای

مدل سیستم لایه‌ای به معماری اجازه می‌دهد تا سیستم سلسله‌مراتبی را پیاده‌سازی کرده و رفتار اجزای مختلف را کنترل کند. در یک سیستم لایه‌ای، هز جزء تنها به لایه خود دسترسی دارد.

امکان اجرای کد

معماری REST با اجرای کدهایی در قالب اسکریپت یا اپلت، امکان توسعه کاربری کلاینت را فراهم می‌کند.  به این ترتیب سرورها می‌توانند بخشی از ویژگی‌ها را در قالب کد به کلاینت ارسال کنند و کلاینت تنها باید کد را اجرا کند.

معماری SOAP

معماری SOAP (مخفف عبارت Simple Object Access Protocol) یک پروتکل برای تبادل داده در سطح شبکه‌ها بوده و برای ساخت API استفاده می‌شود. معماری SOAP به وسیله کنسرسیوم وب جهانی (یا به عبارت دیگر World Wide Web Consortium) استانداردسازی شده و از XML برای انتقال داده‌ها استفاده می‌کند. 

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

به همین دلیل، معماری SOAP بیشتر برای توسعه APIهای داخلی که نیاز به امنیت بیشتر دارند، استفاده می‌شود. مزیت اصلی معماری SOAP این است که روی بستر تمام پروتکل‌های ارتباطی (نه فقط HTTP) کار می‌کند.

ساختار پیام و بلوک‌های معماری SOAP

پیام‌های SOAP در واقع مستندات مبتنی بر XML هستند که شامل سه بلوک زیر می‌‌شوند:

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

بلوک هدر: شامل اطلاعات اضافی درباره پیام است. برای مثال این اطلاعات می‌تواند شامل سندهای احراز هویتی باشد که برای فراخوانی داده‌ها مورد نیاز هستند.

بلوک بدنه: شامل داده‌های پیام است که باید برای وب‌سرویس ارسال شود. این داده‌ها در واقع همان درخواست‌ها و پاسخ‌هایی هستند که تبادل می‌شوند.

معماری RPC

پروتکل RPC (مخفف عبارت Remote Procedural Call) ساده‌ترین معماری در بین معماری‌های API است. بر خلاف دو معماری قبلی، RPC فرایندها را آغاز می‌کند. به عبارت دیگر، APIهای مبتنی بر RPC اسکریپت‌ها را روی سرور اجرا می‌کنند. APIهای مبتنی بر RPC از فرمت‌های JSON یا XML در درخواست‌های خود استفاده می‌کنند. با وجود محدودیت‌های تعریف‌شده در RPC، این معماری راه ساده‌ای اجرای کد روی سرور است.

APIهای مبتنی بر RPC به نسبت دو معماری دیگر از نظر امنیت و قابلیت دچار محدودیت‌هایی هستند و از این رو شما این معماری را کمتر از دو معماری دیگر می‌بینید. 

انتخاب API مناسب

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