API چیست و چه کاربردی دارد؟ آشنایی با انواع API و نحوه کار آن

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

API یا Application Programming Interface یک قرارداد برای ارتباط میان نرم‌افزارهاست؛ مشخص می‌کند چه درخواستی می‌توان ارسال کرد، داده‌ها چه ساختاری داشته باشند و در پاسخ چه چیزی برگردد.

در ادامه می‌بینیم API چیست، Request و Response دقیقاً چه اجزایی دارند و چه مسیری را طی می‌کنند، انواع ای‌پی‌آی چه تفاوتی با هم دارند و در محصولات نرم‌افزاری کجا به کار می‌آیند.

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

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

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

مسیر کلی این ارتباط را می‌توان به شکل زیر نشان داد:

Client، Server و Endpoint

در این مسیر، Client، Server و Endpoint هرکدام نقش مشخصی دارند:

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

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

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

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

اجزای Request و Response

هر بار که Client از طریق ای‌پی‌آی چیزی می‌خواهد، یک Request (درخواست) به سرور می‌فرستد. سرور بعد از بررسی آن، نتیجه را در قالب Response (پاسخ) برمی‌گرداند.

یک Request معمولاً از چند بخش تشکیل می‌شود:

• Endpoint: آدرسی که درخواست به آن ارسال می‌شود.
• Method: مشخص می‌کند قرار است چه کاری انجام شود؛ مثلاً دریافت یا ارسال اطلاعات.
• Header: اطلاعات تکمیلی درخواست را در اختیار Server می‌گذارد؛ مثل نوع داده یا اطلاعات مربوط به احراز هویت.
• Body: داده‌ای است که همراه بعضی از درخواست‌ها برای Server ارسال می‌شود؛ مثلاً اطلاعات لازم برای ثبت یک کاربر جدید.

Response هم فقط شامل داده نهایی نیست. Status Code وضعیت درخواست را مشخص می‌کند؛ برای مثال کد ۲۰۰ یعنی درخواست با موفقیت انجام شده است. داده‌های پاسخ نیز در بسیاری از APIها با فرمت JSON برگردانده می‌شوند؛ فرمتی متنی و ساختاریافته که خواندن و پردازش آن برای برنامه‌ها ساده است.

انواع API را بشناسیم.

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

– انواع API براساس سطح دسترسی

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

• Public API

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

عمومی بودن الزاماً به معنی دسترسی بدون محدودیت نیست. ممکن است برای استفاده از یک Public API به ثبت‌نام، API Key یا رعایت محدودیت تعداد درخواست‌ها نیاز باشد.

• Private API

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

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

• Partner API

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

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

APIها چگونه ارتباط برقرار می‌کنند؟ REST، SOAP، GraphQL و RPC

Public، Private و Partner مشخص می‌کنند چه کسی به ای‌پی‌آی دسترسی دارد. REST، SOAP، GraphQL و RPC موضوع دیگری را توضیح می‌دهند: ارتباط بین دو سیستم چطور طراحی و مدیریت می‌شود.

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

• REST

REST یکی از رایج‌ترین سبک‌های طراحی API است. در این روش، اطلاعات معمولاً به شکل «منبع» در نظر گرفته می‌شوند؛ مثلاً کاربران، محصولات یا سفارش‌ها. هر منبع آدرس مشخصی دارد و کلاینت با ارسال درخواست می‌تواند اطلاعات آن را دریافت کند، تغییر دهد یا مورد جدیدی بسازد.

برای مشخص‌کردن نوع عملیات هم معمولاً از متدهایی مثل GET برای دریافت اطلاعات و POST برای ارسال یا ایجاد اطلاعات استفاده می‌شود.

REST را نباید با خود API یکی دانست. ای‌پی‌آی مفهوم گسترده‌تری است و REST فقط یکی از روش‌های طراحی آن محسوب می‌شود.

• SOAP

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

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

• GraphQL

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

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

• RPC

RPC یا Remote Procedure Call (فراخوانی رویه از راه دور) ارتباط را از زاویه دیگری می‌بیند. در این روش، کلاینت از سرور می‌خواهد یک عملیات مشخص را اجرا کند و نتیجه را برگرداند.

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

اگر در ابتدای مسیر آموزش برنامه‌نویسی هستید، در این مرحله همین تفاوت کلی مهم است: REST بیشتر حول منابع شکل می‌گیرد، GraphQL به کلاینت اجازه می‌دهد داده مورد نیازش را دقیق‌تر انتخاب کند، RPC روی اجرای عملیات تمرکز دارد و SOAP ارتباط را با قواعد و استانداردهای مشخص‌تری تعریف می‌کند.

نمونه ارتباط دو نرم‌افزار با API

تا اینجا فهمیدیم ای‌پی‌آی چطور بین Client و Server ارتباط برقرار می‌کند و یک Request و Response از چه بخش‌هایی تشکیل می‌شوند. حالا می‌توانیم این قطعات را کنار هم بگذاریم و مسیر یک درخواست واقعی را از ارسال تا دریافت پاسخ دنبال کنیم.

فرض کنید Client می‌خواهد وضعیت سفارش شماره ۱۲۳ را از Server دریافت کند. درخواست می‌تواند به این شکل باشد:

GET /orders/123

Host: api.example.com

Authorization: Bearer <token>

Accept: application/json

در این Request:

• Endpoint: مسیر /orders/123 به سفارش مورد نظر اشاره می‌کند.
• Method: متد GET یعنی Client قصد دریافت اطلاعات را دارد.
• Header: اطلاعات تکمیلی درخواست، مثل اطلاعات احراز هویت و فرمت مورد انتظار پاسخ را در اختیار Server قرار می‌دهد.
• Body: این درخواست Body ندارد، چون داده‌ای برای ثبت یا تغییر به Server ارسال نمی‌شود.

اگر درخواست با موفقیت پردازش شود، Server می‌تواند چنین پاسخی برگرداند:

HTTP/1.1 200 OK

Content-Type: application/json

{

  “order_id”: 123,

  “status”: “shipped”,

  “tracking_code”: “TR45821”

}

کد ۲۰۰ نشان می‌دهد درخواست موفق بوده است. داده‌های سفارش نیز با فرمت JSON برگشته‌اند؛ در اینجا status نشان می‌دهد سفارش ارسال شده و tracking_code کد رهگیری آن را در اختیار Client قرار می‌دهد.

در این مثال، Client درخواست مشخصی برای دریافت وضعیت سفارش فرستاد و Server هم بعد از پردازش درخواست، اطلاعات مورد نیاز را در قالب یک Response برگرداند. همین رفت‌وبرگشت، پایه ارتباط بسیاری از نرم‌افزارها از طریق API است.

کاربردهای API در محصولات نرم‌افزاری

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

• پرداخت آنلاین

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

• ورود با حساب کاربری دیگر

گزینه‌هایی مثل «ورود با Google» نمونه دیگری از کاربرد ای‌پی‌آی هستند. در این حالت، سرویس مورد نظر می‌تواند پس از دریافت مجوز کاربر، اطلاعات لازم برای ورود را از سرویس ارائه‌دهنده دریافت کند؛ بدون اینکه رمز عبور آن حساب در اختیار برنامه قرار بگیرد.

• نقشه و موقعیت مکانی

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

• دریافت و نمایش داده از سرویس‌های دیگر

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

• ارتباط بخش‌های مختلف یک محصول

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

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

احراز هویت و امنیت API

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

اینجا دو مفهوم نزدیک اما متفاوت وجود دارد: Authentication (احراز هویت) مشخص می‌کند درخواست از طرف چه کاربر یا سیستمی آمده است؛ Authorization (مجوز دسترسی) تعیین می‌کند آن کاربر یا سیستم اجازه انجام چه کارهایی را دارد.

برای مدیریت این دسترسی روش‌های مختلفی وجود دارد که API Key و Access Token دو نمونه رایج آن هستند.

• API Key

API Key کلیدی است که یک سرویس در اختیار کلاینت قرار می‌دهد و می‌تواند برای شناسایی برنامه یا پروژه‌ای که درخواست را ارسال کرده استفاده شود. این کلید معمولاً همراه Request فرستاده می‌شود و باید از دسترسی افراد غیرمجاز دور بماند.

• Access Token

Access Token مجوزی است که به کلاینت اجازه می‌دهد به منابع یا عملیات مشخصی دسترسی داشته باشد. Token می‌تواند به یک کاربر و سطح دسترسی او وابسته باشد و معمولاً برای مدت مشخصی اعتبار دارد.

• امنیت ارتباط با API

احراز هویت به‌تنهایی برای امن‌کردن ای‌پی‌آی کافی نیست. استفاده از HTTPS باعث می‌شود اطلاعات هنگام انتقال بین Client و Server رمزنگاری شوند. تعیین سطح دسترسی و محدود کردن تعداد درخواست‌ها نیز از اقدامات رایج برای کاهش دسترسی و استفاده غیرمجاز هستند.

API Key ،Token و سایر اطلاعات حساس هم نباید در کدهای عمومی یا بخش‌هایی از برنامه که به‌راحتی در دسترس دیگران قرار می‌گیرند ذخیره شوند.

مزایا و محدودیت‌های استفاده از API

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

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

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

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

برای کار با یک API، از مستندات (Documentation) آن شروع کنید. مستندات نشان می‌دهد چه Endpointهایی در دسترس هستند، هرکدام چه کاری انجام می‌دهند، چه اطلاعاتی دریافت می‌کنند و پاسخ آن‌ها چه ساختاری دارد.

بعد از پیدا کردن Endpoint مورد نیاز، می‌توانید کار را به این ترتیب پیش ببرید:

1. Method و Endpoint را مشخص کنید: بررسی کنید درخواست باید به چه آدرسی و با چه متدی مثل GET یا POST ارسال شود.
2. دسترسی لازم را بگیرید: اگر ای‌پی‌آی به API Key، Access Token یا روش دیگری برای احراز هویت نیاز دارد، اطلاعات لازم را دریافت و به Request اضافه کنید.
3. Request را آماده کنید: Header، پارامترها و در صورت نیاز Body را براساس چیزی که در مستندات آمده تنظیم کنید.
4. درخواست را ارسال کنید: بعد از ارسال Request، داده برگشتی و Status Code را بررسی کنید تا مشخص شود درخواست موفق بوده یا خطایی رخ داده است.
5. خطاها و محدودیت‌ها را مدیریت کنید: قطع ارتباط، پاسخ ناموفق یا عبور از Rate Limit از شرایطی هستند که برنامه باید برای آن‌ها آماده باشد.

برای اولین تجربه هم ضرورتی ندارد API را مستقیماً وارد یک پروژه کنید. ابزارهایی مثل Postman یا دستور cURL اجازه می‌دهند Request را جداگانه ارسال کنید، Header و Body را تغییر دهید و Response را ببینید. به این شکل می‌توانید قبل از نوشتن کد اصلی، رفتار API را بررسی کنید.

جمع‌بندی

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

برای کار با API لازم نیست از همان ابتدا تمام روش‌ها و اصطلاحات را بدانید. مهم این است که بتوانید مسیر یک درخواست را دنبال کنید: Request به کدام Endpoint می‌رود، سرور با آن چه می‌کند و Response چه اطلاعاتی برمی‌گرداند.

بعد از آن، نوبت تجربه واقعی است. مستندات یک API را باز کنید و اولین Request را بفرستید؛ چون ارتباط بین نرم‌افزارها روی کاغذ یاد گرفته نمی‌شود، باید آن را در عمل دید.