وقتی اپلیکیشن هواشناسی دمای شهر را نشان میدهد، فروشگاه اینترنتی وضعیت پرداخت را از درگاه میگیرد یا برنامه موبایل اطلاعات حساب شما را از سرور دریافت میکند، معمولاً یک API در میان است. API یا رابط برنامهنویسی کاربردی قراردادی است که مشخص میکند دو نرمافزار چگونه با هم ارتباط برقرار کنند؛ چه درخواستی قابل ارسال است، داده با چه قالبی برمیگردد و در صورت خطا چه اتفاقی میافتد.
API فقط مخصوص وب نیست. سیستمعامل، کتابخانه برنامهنویسی، سختافزار و سرویس ابری هم میتوانند API داشته باشند. اما در توسعه مدرن، Web APIها یکی از مهمترین روشهای اتصال فرانتاند، بکاند و سرویسهای مختلفاند. در این راهنما مفهوم API، نحوه کار، REST و GraphQL، احراز هویت، Rate Limit، امنیت و مدلهای کسبوکار API را بررسی میکنیم.
API چیست؟ یک مثال ساده
فرض کنید برنامه شما برای تبدیل ارز به نرخ روز نیاز دارد. میتوانید خودتان سامانه جمعآوری نرخ بسازید، اما سادهتر است از API یک سرویس معتبر استفاده کنید. سرویس مجموعهای از Endpointها تعریف میکند؛ مثلاً یک آدرس برای دریافت نرخ ارز. برنامه درخواست را با پارامترهای مشخص میفرستد و پاسخ ساختاریافته، اغلب JSON، دریافت میکند.
این قرارداد باعث میشود شما لازم نباشد بدانید سرویس در داخل از چه پایگاه داده یا زبان برنامهنویسی استفاده میکند. تا زمانی که API طبق قرارداد کار کند، پیادهسازی داخلی میتواند تغییر کند بدون اینکه مصرفکننده مجبور به بازنویسی کامل شود.
جمعبندی تحریریه از مقدمه MDN درباره Web APIها: MDN API را مجموعهای از قابلیتها میداند که توسعهدهنده میتواند بدون درگیرشدن با جزئیات پیچیده پیادهسازی داخلی از آنها استفاده کند. API یک لایه انتزاع میسازد: بهجای اینکه برنامهنویس همه منطق سطح پایین را خودش بنویسد، از توابع، اشیا یا Endpointهای تعریفشده استفاده میکند. همین اصل از APIهای مرورگر تا سرویسهای وب برقرار است. مطالعه مقدمه رسمی MDN درباره APIها
API چگونه کار میکند؟
در Web API معمولاً یک Client درخواست را به Server میفرستد. درخواست شامل آدرس، روش HTTP، Headerها و در بعضی موارد Body است. سرور درخواست را اعتبارسنجی میکند، منطق لازم را اجرا میکند و پاسخ همراه با Status Code و داده برمیگرداند.
Endpoint
Endpoint یک مسیر مشخص از API است. برای نمونه /users میتواند فهرست کاربران و /users/42 اطلاعات کاربر شماره ۴۲ را نمایندگی کند. طراحی مسیرها به سبک API بستگی دارد.
روشهای HTTP
- GET: دریافت داده بدون تغییر منبع.
- POST: معمولاً برای ایجاد منبع یا اجرای عملیات.
- PUT: جایگزینی یا بهروزرسانی کامل منبع.
- PATCH: تغییر بخشی از منبع.
- DELETE: حذف منبع.
Status Code
کدهای 2xx معمولاً موفقیت، 4xx مشکل درخواست یا مجوز Client و 5xx خطای سمت Server را نشان میدهند. برای مثال 200 یعنی درخواست موفق، 201 ایجاد موفق منبع، 400 درخواست نامعتبر، 401 نیاز به احراز هویت، 403 عدم مجوز و 404 پیدا نشدن منبع.
فرانتاند و بکاند چگونه از API استفاده میکنند؟
در یک اپ مدرن، رابط کاربری لازم نیست مستقیماً به پایگاه داده متصل شود. فرانتاند درخواست را به API بکاند میفرستد؛ بکاند دسترسی را کنترل میکند، داده را از دیتابیس یا سرویس دیگر میگیرد و نتیجه مناسب را برمیگرداند. این جداسازی اجازه میدهد همان بکاند به وبسایت، اپ اندروید و iOS سرویس بدهد.
همچنین API میتواند بین سرویسهای بکاند ارتباط برقرار کند؛ مثلاً سرویس سفارش با سرویس پرداخت، انبار و ارسال. در معماری میکروسرویس، طراحی مرز APIها یکی از تصمیمهای اصلی معماری است.
REST API چیست؟
REST یک سبک معماری برای سیستمهای توزیعشده است و Web APIهای زیادی از اصول آن الهام میگیرند. در APIهای RESTful، منابع با URL نمایش داده میشوند و عملیات با روشهای استاندارد HTTP انجام میشود. پاسخ اغلب JSON است. Stateless بودن نیز اصل مهمی است؛ هر درخواست باید اطلاعات لازم برای پردازش را همراه داشته باشد و سرور نباید برای فهم درخواست به وضعیت مخفی قبلی وابسته باشد.
REST یک پروتکل یا فرمت اجباری واحد نیست. API میتواند HTTP و JSON داشته باشد اما همه اصول REST را رعایت نکند. در عمل اصطلاح «REST API» گاهی با معنای گستردهتری استفاده میشود.
GraphQL چه تفاوتی با REST دارد؟
GraphQL زبان Query و Runtime برای API است که به Client اجازه میدهد دقیقاً فیلدهای موردنیاز را درخواست کند. در REST ممکن است برای اطلاعات صفحه چند Endpoint صدا زده شود یا پاسخ دادهای بیشتر از نیاز داشته باشد. GraphQL میتواند این مسئله را کاهش دهد، اما پیچیدگیهایی مانند caching، کنترل Queryهای پرهزینه و مجوز سطح فیلد دارد.
هیچکدام همیشه بهتر نیستند. REST برای بسیاری از سرویسهای عمومی ساده و قابلفهم است؛ GraphQL در رابطهایی با نیاز داده متنوع میتواند مفید باشد. انتخاب باید بر اساس نیاز محصول، تیم و عملیات انجام شود.
WebSocket و Webhook هم API هستند؟
WebSocket یک ارتباط دوطرفه و پایدار بین Client و Server ایجاد میکند و برای چت، بازی آنلاین یا داده بلادرنگ مناسب است. Webhook برعکس Polling، اجازه میدهد سرویس هنگام رخداد مشخص به URL شما درخواست بفرستد؛ مثلاً درگاه پرداخت پس از تغییر وضعیت تراکنش به سرور فروشگاه اطلاع دهد.
Webhook باید مانند ورودی خارجی غیرقابل اعتماد دیده شود: امضای درخواست، زمان، replay protection و اعتبارسنجی داده را بررسی کنید.
احراز هویت در API چگونه انجام میشود؟
API Key
کلید API شناسه یا Secretی است که مصرفکننده را مشخص میکند. برای سرویس سمت سرور کاربرد دارد، اما نباید Secret خصوصی را داخل کد JavaScript عمومی یا اپی که قابل استخراج است قرار داد. Key باید قابل لغو و چرخش باشد.
Token و OAuth 2.0
Token میتواند دسترسی محدود و زماندار ایجاد کند. OAuth 2.0 چارچوبی برای اعطای دسترسی بدون دادن مستقیم رمز کاربر به برنامه ثالث است. جریان مناسب به نوع برنامه وابسته است و استفاده از کتابخانه و سرویس استاندارد بسیار امنتر از طراحی پروتکل احراز هویت اختصاصی است.
Rate Limit چرا مهم است؟
APIها معمولاً تعداد درخواست مجاز را در بازه زمانی محدود میکنند تا از سوءاستفاده، خطای Client و مصرف نامتناسب منابع جلوگیری شود. وقتی حد عبور کند، سرور ممکن است پاسخ 429 برگرداند. Client خوب باید Retry را با backoff انجام دهد و کورکورانه درخواست را تکرار نکند.
نسخهبندی API و سازگاری
تغییر API عمومی میتواند صدها مصرفکننده را بشکند. بنابراین تغییرات Breaking باید برنامهریزی شوند. بعضی سرویسها نسخه را در URL مانند /v1/ میگذارند و بعضی از Header استفاده میکنند. مهمتر از شکل نسخهبندی، سیاست روشن Deprecation، مستندات Migration و زمان کافی برای مهاجرت است.
یک API خوب چه ویژگیهایی دارد؟
- نامگذاری و رفتار Endpointها قابل پیشبینی است.
- خطاها ساختار روشن و پیام قابل استفاده دارند.
- مستندات، مثال و محیط آزمایشی وجود دارد.
- احراز هویت و مجوز بهدرستی تفکیک شدهاند.
- Idempotency برای عملیات حساس مانند پرداخت در نظر گرفته شده است.
- Rate Limit و quota مستند است.
- لاگ و Trace برای عیبیابی وجود دارد بدون اینکه Secret ثبت شود.
- تغییرات Breaking با نسخه و دوره مهاجرت مدیریت میشوند.
امنیت API؛ رایجترین ریسکها
بخش بزرگی از امنیت API به کنترل دسترسی مربوط است. صرف اینکه کاربر وارد شده، به معنی مجاز بودن برای مشاهده هر شناسه نیست. سرور باید برای هر منبع مجوز را کنترل کند. Validation ورودی، محدودکردن نرخ، استفاده از HTTPS، مدیریت Secret، Patch وابستگیها و محدودکردن اطلاعات خطا از اصول پایهاند.
API Gateway و WAF میتوانند بخشی از کنترلها را مرکزی کنند، اما جای طراحی امن Business Logic را نمیگیرند. تست امنیت باید سناریوهای واقعی مانند تغییر ID، دستکاری نقش، تکرار درخواست و استفاده از Token منقضی را هم پوشش دهد.
چگونه از API درآمد کسب میشود؟
API ممکن است خود محصول باشد یا راهی برای توسعه اکوسیستم یک محصول. مدلهای رایج شامل پلن رایگان با quota محدود، پرداخت بهازای مصرف، اشتراک ماهانه، پلن سازمانی و تقسیم درآمد هستند. سرویسهای پیامک، پرداخت، نقشه، هوش مصنوعی و داده نمونههای شناختهشده اقتصاد API هستند.
برای API پولی، قیمت تنها مسئله نیست؛ SLA، پایداری، کیفیت مستندات، پشتیبانی، محدودیت نرخ، محل پردازش داده و سیاست نگهداری اطلاعات برای مشتری سازمانی اهمیت زیادی دارد.
API را از کجا شروع کنیم؟
اگر برنامهنویس تازهکار هستید، با یک API عمومی ساده شروع کنید. با ابزارهایی مانند curl یا Postman یک GET بفرستید، JSON پاسخ را بخوانید و سپس همان درخواست را در زبان خود اجرا کنید. بعد پارامتر، خطا و احراز هویت را اضافه کنید. در مرحله بعد یک API کوچک خودتان بسازید و برایش مستندات بنویسید؛ این تمرین دید دوطرفه مصرفکننده و ارائهدهنده را ایجاد میکند.
جمعبندی
API قرارداد ارتباط بین نرمافزارهاست و یکی از پایههای معماری مدرن محسوب میشود. Endpoint، درخواست/پاسخ، روش HTTP، احراز هویت، Rate Limit و نسخهبندی اجزای عملی مهم آن هستند. REST، GraphQL، WebSocket و Webhook هرکدام مسئله متفاوتی حل میکنند و انتخاب صحیح به الگوی داده و تعامل سیستم وابسته است. API خوب فقط «کار میکند»؛ بلکه قابل فهم، پایدار، امن، مستند و قابل تغییر در طول زمان است.
