مقدمه

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

عامل اصلی این ارتباط‌ها معمولاً API است.

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

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

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

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

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

در پروژه‌های طراحی سایت و نرم‌افزار تحت وب، تیم‌هایی مانند اسمارتی اپ (SmartyApp) معمولاً از API برای اتصال رابط کاربری، اپلیکیشن موبایل، سرویس‌های سازمانی و سامانه‌های بیرونی استفاده می‌کنند. در ادامه، این مفهوم را از پایه تا سطح فنی و اجرایی بررسی می‌کنیم.

API چیست؟

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

یک API معمولاً مشخص می‌کند:

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

برای مثال، API یک سامانه فروش ممکن است عملیات‌های زیر را ارائه دهد:

GET    /api/customers POST   /api/customers GET    /api/customers/125 PATCH  /api/customers/125 DELETE /api/customers/125

این مسیرها به‌ترتیب می‌توانند برای دریافت فهرست مشتریان، ایجاد مشتری، دریافت یک مشتری، ویرایش و حذف آن استفاده شوند.

نکته مهم این است که مصرف‌کننده API لزوماً نمی‌داند در پشت این مسیرها چه اتفاقی می‌افتد. ممکن است سامانه با PHP، Java، Node.js یا C# نوشته شده باشد و اطلاعات را در MySQL، PostgreSQL یا سرویس دیگری نگهداری کند. مصرف‌کننده فقط قرارداد API را می‌بیند.

یک مثال ساده برای درک API

فرض کنید در رستوران نشسته‌اید. شما سفارش خود را به پیشخدمت می‌گویید. پیشخدمت درخواست را به آشپزخانه منتقل می‌کند و غذای آماده را برای شما می‌آورد.

در این تشبیه:

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

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

API نیز همین لایه واسط و کنترل‌شده را میان نرم‌افزارها ایجاد می‌کند.

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

در ساده‌ترین حالت، ارتباط API شامل دو نقش است:

Client یا سرویس‌گیرنده

برنامه‌ای است که درخواست را ارسال می‌کند؛ مانند:

• مرورگر؛
• اپلیکیشن موبایل؛
• نرم‌افزار حسابداری؛
• پنل مدیریت؛
• سامانه یک شرکت دیگر؛
• دستگاه صنعتی یا اینترنت اشیا.

Server یا سرویس‌دهنده

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

پیام‌های HTTP به دو گروه اصلی تقسیم می‌شوند: Requestهایی که کلاینت برای اجرای یک عملیات ارسال می‌کند و Responseهایی که سرور در پاسخ برمی‌گرداند.

جریان یک درخواست API

فرض کنید اپلیکیشن فروش می‌خواهد اطلاعات سفارش شماره ۸۷۵ را دریافت کند:

GET /api/v1/orders/875 HTTP/1.1 Host: example.com Authorization: Bearer TOKEN Accept: application/json

سرور پس از بررسی توکن و سطح دسترسی، ممکن است این پاسخ را برگرداند:

{    "id": 875,    "customer": {        "id": 42,        "name": "شرکت نمونه"    },    "status": "processing",    "total_amount": 18500000,    "currency": "IRR" }

اگر سفارش وجود نداشته باشد، پاسخ می‌تواند چنین باشد:

{    "message": "سفارش موردنظر پیدا نشد." }

همراه این پاسخ، کد وضعیت 404 ارسال می‌شود.

اجزای اصلی یک API

Endpoint چیست؟

Endpoint آدرسی است که یک قابلیت مشخص از API را ارائه می‌کند.

برای مثال:

/api/v1/products /api/v1/orders /api/v1/users/15 /api/v1/reports/sales

هر Endpoint باید هدف مشخصی داشته باشد. طراحی نامنظم مسیرها باعث می‌شود استفاده و نگهداری API دشوار شود.

HTTP Method چیست؟

متد HTTP هدف درخواست را مشخص می‌کند. HTTP برای عملیات مختلف، متدهایی با معناهای مشخص تعریف کرده است. برخی از این متدها ویژگی‌هایی مانند Safe، Idempotent یا Cacheable دارند.

طبق مستندات MDN، متد GET برای دریافت نمایش یک منبع استفاده می‌شود و نباید برای تغییر داده به کار رود. POST نیز برای ارسال داده به سرور استفاده می‌شود و نوع محتوای بدنه درخواست از طریق Headerهایی مانند Content-Type مشخص می‌شود.

Header چیست؟

Headerها اطلاعات تکمیلی درخواست و پاسخ را حمل می‌کنند.

نمونه‌ها:

Content-Type: application/json Accept: application/json Authorization: Bearer TOKEN User-Agent: MobileApp/2.1 Cache-Control: no-cache

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

Body چیست؟

Body یا بدنه، داده اصلی درخواست یا پاسخ است.

برای ثبت مشتری جدید:

{    "name": "علی رضایی",    "mobile": "09120000000",    "company": "شرکت نمونه" }

همه درخواست‌ها Body ندارند. برای مثال، در یک درخواست GET معمولاً فیلترها از طریق Query String ارسال می‌شوند:

GET /api/v1/orders?status=paid&page=2

Status Code چیست؟

کد وضعیت نتیجه درخواست را نشان می‌دهد.

برخی کدهای پرکاربرد:

• 200 OK: درخواست موفق بود؛
• 201 Created: منبع جدید ایجاد شد؛
• 204 No Content: عملیات موفق بود اما بدنه‌ای وجود ندارد؛
• 400 Bad Request: ساختار درخواست نادرست است؛
• 401 Unauthorized: احراز هویت لازم یا نامعتبر است؛
• 403 Forbidden: کاربر شناسایی شده اما مجوز ندارد؛
• 404 Not Found: منبع پیدا نشد؛
• 422 Unprocessable Content: داده‌ها از نظر اعتبارسنجی قابل‌قبول نیستند؛
• 429 Too Many Requests: تعداد درخواست‌ها بیش از حد مجاز است؛
• 500 Internal Server Error: خطایی در سرور رخ داده است.

تعاریف رسمی متدها، کدهای وضعیت و معنای پیام‌های HTTP در استاندارد HTTP Semantics یا RFC 9110 ارائه شده است.

تفاوت API و Web Service چیست؟

این دو اصطلاح گاهی به‌جای یکدیگر استفاده می‌شوند، اما کاملاً یکسان نیستند.

API مفهوم گسترده‌تری دارد. API می‌تواند:

• داخل یک برنامه باشد؛
• رابط یک کتابخانه باشد؛
• رابط سیستم‌عامل باشد؛
• از شبکه استفاده کند؛
• مبتنی بر HTTP یا پروتکل دیگری باشد.

Web Service نوعی API است که از طریق شبکه و فناوری‌های وب در دسترس قرار می‌گیرد.

به بیان ساده:

هر Web Service یک API است، اما هر API الزاماً Web Service نیست.

برای مثال، توابعی که یک کتابخانه PHP در اختیار برنامه‌نویس قرار می‌دهد API محسوب می‌شوند، حتی اگر هیچ درخواست شبکه‌ای در کار نباشد.

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

API عمومی یا Public API

این API در اختیار توسعه‌دهندگان بیرونی قرار می‌گیرد. ممکن است رایگان یا تجاری باشد.

نمونه کاربرد:

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

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

API خصوصی یا Internal API

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

برای مثال:

• ارتباط CRM با حسابداری؛
• ارتباط پنل مدیریت با سرویس گزارش؛
• ارتباط اپلیکیشن کارکنان با منابع انسانی؛
• ارتباط سرویس سفارش با انبار.

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

API شریک تجاری یا Partner API

فقط در اختیار شرکت‌ها یا همکاران مشخص قرار می‌گیرد.

مثلاً یک تولیدکننده می‌تواند API ثبت سفارش را در اختیار نمایندگان رسمی خود قرار دهد.

Composite API

چند عملیات یا منبع را در یک درخواست ترکیب می‌کند.

برای مثال، داشبورد مدیریتی ممکن است در یک درخواست، آمار فروش، سفارش‌های باز و موجودی بحرانی را دریافت کند.

این روش تعداد رفت‌وبرگشت‌های شبکه را کاهش می‌دهد، اما باید با دقت طراحی شود تا Endpoint بیش از حد پیچیده نشود.

معماری‌ها و سبک‌های رایج API

REST API چیست؟

REST مخفف Representational State Transfer است. REST یک سبک معماری برای طراحی سامانه‌های توزیع‌شده است و در بسیاری از APIهای تحت وب استفاده می‌شود.

در REST، مفاهیم کسب‌وکار به شکل Resource مدل می‌شوند:

/customers /orders /products /invoices

عملیات نیز با متدهای HTTP انجام می‌شوند:

GET    /orders POST   /orders GET    /orders/25 PATCH  /orders/25 DELETE /orders/25

ویژگی‌های رایج REST API

• استفاده از منابع قابل‌شناسایی؛
• استفاده درست از متدهای HTTP؛
• Stateless بودن درخواست‌ها؛
• پاسخ‌های ساختاریافته؛
• امکان استفاده از کش؛
• جدایی Client و Server؛
• استفاده از کدهای وضعیت استاندارد.

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

GraphQL چیست؟

GraphQL روشی برای پرس‌وجو از API است که در آن Client مشخص می‌کند دقیقاً چه فیلدهایی را می‌خواهد.

مثال:

query {  order(id: 875) {    id    status    customer {      name    }    items {      productName      quantity    }  } }

مزیت مهم GraphQL این است که Client می‌تواند داده موردنیاز را در ساختار مشخص دریافت کند و از دریافت اطلاعات اضافی جلوگیری شود.

اما GraphQL چالش‌هایی نیز دارد:

• کنترل پیچیدگی Query؛
• کش دشوارتر در برخی سناریوها؛
• نیاز به محدودسازی عمق درخواست؛
• ریسک دریافت حجم بالای داده؛
• پیچیدگی مجوزدهی در سطح فیلد.

GraphQL همیشه جایگزین بهتر REST نیست. انتخاب میان این دو باید بر اساس نوع محصول، نیاز Clientها و پیچیدگی داده انجام شود.

SOAP چیست؟

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

ویژگی‌های آن:

• قرارداد رسمی WSDL؛
• ساختار XML؛
• استانداردهای گسترده امنیت و تراکنش؛
• سخت‌گیری بیشتر در قالب پیام؛
• حجم داده و پیچیدگی بالاتر نسبت به بسیاری از REST APIها.

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

RPC و gRPC

در مدل RPC، API مانند فراخوانی یک تابع از راه دور طراحی می‌شود:

CreateOrder CalculateShippingCost ApproveInvoice

gRPC یک فناوری RPC است که معمولاً از Protocol Buffers استفاده می‌کند و برای ارتباط سریع میان سرویس‌های داخلی مناسب است.

کاربردهای رایج:

• میکروسرویس‌ها؛
• سیستم‌های پرترافیک؛
• ارتباط کم‌تأخیر؛
• Streaming؛
• محیط‌های چندزبانه.

برای API عمومی مرورگر، REST معمولاً ساده‌تر است؛ اما برای ارتباط داخلی سرویس‌ها، gRPC می‌تواند کارایی مناسبی داشته باشد.

WebSocket

WebSocket برای ارتباط دوطرفه و مداوم میان Client و Server استفاده می‌شود.

کاربردها:

• چت آنلاین؛
• اعلان لحظه‌ای؛
• قیمت زنده؛
• داشبورد مانیتورینگ؛
• بازی آنلاین؛
• رهگیری لحظه‌ای ناوگان.

WebSocket جایگزین همه APIهای HTTP نیست. بسیاری از سیستم‌ها برای عملیات عادی از REST و برای رویدادهای بلادرنگ از WebSocket استفاده می‌کنند.

API چه کاربردی در نرم‌افزار دارد؟

اتصال Front-end به Back-end

در بسیاری از نرم‌افزارهای مدرن، رابط کاربری و منطق سرور از هم جدا هستند.

برای مثال:

• React یا Vue رابط کاربری را نمایش می‌دهد؛
• Laravel یا Node.js API را ارائه می‌کند؛
• API اطلاعات را از دیتابیس دریافت می‌کند؛
• پاسخ JSON به Front-end فرستاده می‌شود.

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

اتصال اپلیکیشن موبایل

اپلیکیشن Android و iOS معمولاً برای ثبت‌نام، ورود، دریافت محصولات، ثبت سفارش و نمایش اعلان‌ها از API استفاده می‌کنند.

یک API واحد می‌تواند هم‌زمان به این Clientها سرویس بدهد:

• وب‌سایت؛
• اپلیکیشن اندروید؛
• اپلیکیشن iOS؛
• پنل کارکنان؛
• دستگاه فروش.

اتصال نرم‌افزارهای سازمانی

API می‌تواند میان CRM، ERP، انبار و حسابداری ارتباط ایجاد کند.

مثال:

1. سفارش در CRM ثبت می‌شود.
2. API سفارش را به انبار می‌فرستد.
3. موجودی رزرو می‌شود.
4. فاکتور در حسابداری ایجاد می‌شود.
5. کد رهگیری به CRM بازمی‌گردد.
6. پیامک برای مشتری ارسال می‌شود.

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

اتصال به درگاه پرداخت

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

فرآیند معمول:

1. فروشگاه مبلغ و شماره سفارش را ارسال می‌کند.
2. درگاه یک توکن پرداخت برمی‌گرداند.
3. کاربر به صفحه پرداخت منتقل می‌شود.
4. پس از پرداخت به فروشگاه بازمی‌گردد.
5. فروشگاه با API نتیجه را تأیید می‌کند.
6. وضعیت سفارش به پرداخت‌شده تغییر می‌کند.

ارسال پیامک و ایمیل

سامانه اطلاعات پیام و گیرنده را به API ارائه‌دهنده ارسال می‌کند:

{    "mobile": "09120000000",    "template": "order-created",    "parameters": {        "order_id": "875"    } }

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

نقشه و مسیریابی

کسب‌وکارهای لجستیک، فروشگاه‌ها و سامانه‌های خدماتی می‌توانند از API نقشه برای موارد زیر استفاده کنند:

• تبدیل آدرس به مختصات؛
• نمایش محل مشتری؛
• محاسبه فاصله؛
• پیشنهاد مسیر؛
• محاسبه هزینه ارسال؛
• مدیریت محدوده خدمات.

گزارش‌گیری و هوش تجاری

API می‌تواند داده‌های کنترل‌شده را به داشبورد مدیریتی یا ابزار BI ارائه کند.

مزیت این روش آن است که ابزار گزارش‌گیری به‌صورت مستقیم به جداول حساس دیتابیس متصل نمی‌شود.

هوش مصنوعی

سرویس‌های هوش مصنوعی نیز معمولاً از طریق API در نرم‌افزارها استفاده می‌شوند.

نمونه‌ها:

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

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

مثال‌های واقعی API برای کسب‌وکارها

مثال اول: فروشگاه اینترنتی

یک فروشگاه ممکن است از چند API استفاده کند:

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

مثال دوم: شرکت خدمات پس از فروش

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

1. فهرست مأموریت‌ها از API دریافت می‌شود.
2. موقعیت تکنسین ثبت می‌شود.
3. تصویر دستگاه بارگذاری می‌شود.
4. قطعات مصرفی ثبت می‌شوند.
5. مشتری امضا می‌کند.
6. گزارش به سامانه مرکزی ارسال می‌شود.
7. حسابداری هزینه را دریافت می‌کند.

مثال سوم: کارخانه

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

• سفارش فروش؛
• برنامه‌ریزی تولید؛
• کنترل موجودی؛
• دستگاه‌های صنعتی؛
• کنترل کیفیت؛
• حسابداری؛
• داشبورد مدیریت.

در این مدل، API از انتقال دستی اطلاعات جلوگیری می‌کند.

مثال چهارم: سامانه رزرو

سامانه رزرو یک مرکز خدماتی ممکن است به تقویم، پرداخت و پیامک متصل باشد.

پس از انتخاب زمان:

• ظرفیت از API بررسی می‌شود؛
• رزرو ثبت می‌شود؛
• پرداخت ایجاد می‌شود؛
• پیامک تأیید ارسال می‌شود؛
• رویداد در تقویم کارشناس قرار می‌گیرد.

مثال پنجم: پورتال نمایندگان

نماینده می‌تواند از طریق API:

• موجودی محصول را ببیند؛
• قیمت اختصاصی دریافت کند؛
• سفارش ثبت کند؛
• مانده حساب را ببیند؛
• وضعیت ارسال را پیگیری کند.

در پروژه‌های تولید نرم‌افزار اختصاصی، اسمارتی اپ (SmartyApp) می‌تواند API را به‌عنوان لایه ارتباطی میان پورتال، سامانه مرکزی و نرم‌افزارهای جانبی در نظر بگیرد تا توسعه‌های آینده به تغییر مستقیم هسته سیستم وابسته نباشند.

احراز هویت در API

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

API Key

یک کلید مشخص به مصرف‌کننده داده می‌شود:

X-API-Key: abc123

این روش ساده است اما برای دسترسی‌های حساس به‌تنهایی کافی نیست. کلید باید قابل لغو، محدود و قابل چرخش باشد.

Bearer Token

Client پس از ورود یک توکن دریافت می‌کند:

Authorization: Bearer eyJ...

سرور بر اساس توکن، کاربر و مجوزهای او را بررسی می‌کند.

OAuth 2.0

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

مثال رایج:

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

OAuth جریان‌های مختلفی دارد و باید متناسب با نوع Client انتخاب شود.

JWT

JWT یک قالب Token است و می‌تواند اطلاعاتی مانند شناسه کاربر، زمان انقضا و سطح دسترسی را حمل کند.

JWT لزوماً بهترین انتخاب برای همه پروژه‌ها نیست. لغو توکن، اندازه Token و نگهداری امن آن باید در طراحی بررسی شوند.

Session Authentication

در برنامه‌های وب سنتی، Session و Cookie نیز می‌توانند برای احراز هویت API داخلی استفاده شوند.

انتخاب روش مناسب به نوع Client، دامنه امنیتی، معماری و طول عمر دسترسی بستگی دارد.

تفاوت احراز هویت و مجوزدهی

این دو مفهوم نباید با هم اشتباه شوند.

Authentication پاسخ می‌دهد:

چه کسی درخواست را ارسال کرده است؟

Authorization پاسخ می‌دهد:

این کاربر اجازه انجام چه عملی را دارد؟

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

یکی از مهم‌ترین ریسک‌های API، Broken Object Level Authorization است؛ یعنی API شناسه یک شیء را دریافت کند اما بررسی نکند کاربر واقعاً اجازه دسترسی به آن را دارد یا خیر. OWASP بررسی مجوز در هر تابعی که بر اساس شناسه کاربر به داده دسترسی می‌دهد را ضروری می‌داند.

نمونه آسیب‌پذیر:

GET /api/orders/875

اگر کاربر بتواند عدد 875 را به 876 تغییر دهد و سفارش فرد دیگری را ببیند، API دارای نقص کنترل دسترسی است.

امنیت API

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

پروژه رسمی OWASP API Security Top 10 مهم‌ترین ریسک‌های امنیتی API را پوشش می‌دهد؛ از جمله ضعف مجوزدهی در سطح شیء، ضعف احراز هویت، مصرف نامحدود منابع، دسترسی به جریان‌های حساس کسب‌وکار، SSRF، مدیریت نامناسب موجودی API و اعتماد ناامن به APIهای ثالث.

اعتبارسنجی ورودی‌ها

هر ورودی باید بررسی شود:

• نوع داده؛
• طول؛
• محدوده عددی؛
• فرمت؛
• وجود رکورد مرتبط؛
• مجازبودن مقدار؛
• سطح دسترسی؛
• نوع و اندازه فایل.

نمونه اعتبارسنجی:

{    "quantity": 4,    "product_id": 25 }

سرور نباید فقط بررسی کند quantity عدد است. باید مثبت‌بودن مقدار، وجود محصول و مجازبودن خرید را نیز بررسی کند.

Rate Limiting

Rate Limit تعداد درخواست مجاز را محدود می‌کند.

مثلاً:

100 requests per minute

این کنترل برای جلوگیری از سوءاستفاده، حمله Brute Force و مصرف بیش از حد منابع اهمیت دارد.

HTTPS

اطلاعات API باید از طریق HTTPS منتقل شوند تا داده‌ها در مسیر قابل‌خواندن یا تغییر نباشند.

محدودسازی خروجی

API نباید تمام ستون‌های یک مدل را بدون کنترل برگرداند.

اطلاعاتی مانند موارد زیر نباید ناخواسته افشا شوند:

• رمز عبور؛
• Token؛
• کلیدهای داخلی؛
• اطلاعات مالی غیرضروری؛
• یادداشت‌های محرمانه؛
• ستون‌های مدیریتی.

جلوگیری از Mass Assignment

اگر Client تمام فیلدها را مستقیماً به مدل ارسال کند، ممکن است بتواند فیلدهایی مانند role یا is_admin را تغییر دهد.

سرور باید فیلدهای مجاز را به‌صورت صریح مشخص کند.

مدیریت خطا

پاسخ خطا نباید Stack Trace، مسیر فایل، Query دیتابیس یا کلیدهای محرمانه را نمایش دهد.

پاسخ مناسب:

{    "message": "خطایی در پردازش درخواست رخ داد.",    "trace_id": "6f7a2d" }

ثبت لاگ و پایش

موارد مهم:

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

لاگ نباید شامل رمز عبور یا Token کامل باشد.

اعتماد نکردن به APIهای ثالث

داده دریافتی از یک API دیگر نیز باید مانند ورودی کاربر اعتبارسنجی شود. OWASP «مصرف ناامن APIها» را یکی از ریسک‌های اصلی معرفی می‌کند؛ زیرا توسعه‌دهندگان ممکن است به داده سرویس ثالث بیش از حد اعتماد کنند.

طراحی درست API

نام‌گذاری واضح

بهتر:

GET /api/v1/customers GET /api/v1/orders/25

نامناسب:

GET /api/getAllCustomerData GET /api/doOrderAction

در REST بهتر است مسیرها منابع را نشان دهند و عملیات از طریق متد HTTP مشخص شود.

استفاده از اسم جمع

/products /customers /orders

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

فیلتر و صفحه‌بندی

برای فهرست‌های بزرگ:

GET /api/v1/orders?status=paid&page=2&per_page=25

پاسخ:

{    "data": [],    "meta": {        "current_page": 2,        "per_page": 25,        "total": 420    } }

نباید هزاران رکورد در یک پاسخ ارسال شود.

مرتب‌سازی

GET /api/v1/products?sort=-created_at

علامت منفی می‌تواند ترتیب نزولی را نشان دهد.

انتخاب فیلد

در بعضی APIها:

GET /api/v1/customers?fields=id,name,mobile

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

پاسخ خطای ثابت

تمام خطاها باید ساختار یکسانی داشته باشند:

{    "message": "اطلاعات واردشده معتبر نیست.",    "errors": {        "mobile": [            "شماره موبایل قبلاً ثبت شده است."        ]    } }

Idempotency

Idempotent بودن یعنی اجرای چندباره یک درخواست، اثر نهایی ناخواسته ایجاد نکند.

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

می‌توان از یک کلید استفاده کرد:

Idempotency-Key: order-875-payment-1

Timeout و Retry

هنگام اتصال به API بیرونی باید Timeout مشخص باشد. Retry نیز باید محدود و ترجیحاً همراه با فاصله افزایشی انجام شود.

Retry کورکورانه روی عملیات غیر Idempotent ممکن است عملیات را دوباره اجرا کند.

نسخه‌بندی API

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

روش رایج:

/api/v1/orders /api/v2/orders

روش‌های دیگر شامل نسخه در Header یا Content Type هستند.

چه تغییراتی ناسازگار هستند؟

• حذف فیلد؛
• تغییر نام فیلد؛
• تغییر نوع داده؛
• حذف Endpoint؛
• اجباری‌کردن پارامتر جدید؛
• تغییر معنای Status Code؛
• تغییر ساختار پاسخ.

چه تغییراتی معمولاً سازگارترند؟

• اضافه‌کردن Endpoint جدید؛
• اضافه‌کردن فیلد اختیاری؛
• اضافه‌کردن فیلتر اختیاری؛
• بهبود عملکرد بدون تغییر قرارداد.

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

مستندسازی API

API بدون مستندات مناسب، حتی اگر از نظر فنی خوب باشد، استفاده‌پذیری پایینی خواهد داشت.

مستندات باید شامل موارد زیر باشند:

• آدرس پایه؛
• روش احراز هویت؛
• Endpointها؛
• متدها؛
• پارامترها؛
• نمونه Request؛
• نمونه Response؛
• کدهای خطا؛
• محدودیت مصرف؛
• نسخه API؛
• Webhookها؛
• محیط آزمایشی؛
• تاریخ تغییرات.

OpenAPI چیست؟

OpenAPI یک استاندارد مستقل از زبان برنامه‌نویسی برای توصیف APIهای مبتنی بر HTTP است. این استاندارد به انسان‌ها و ابزارها اجازه می‌دهد قابلیت‌های یک سرویس را بدون بررسی سورس‌کد یا تحلیل ترافیک شبکه درک کنند. آخرین نسخه منتشرشده‌ای که در مرجع رسمی ثبت شده، OpenAPI 3.2.0 است.

نمونه ساده:

openapi: 3.2.0 info:  title: Orders API  version: 1.0.0 paths:  /orders/{orderId}:    get:      summary: دریافت اطلاعات سفارش      parameters:        - name: orderId          in: path          required: true          schema:            type: integer      responses:        '200':          description: سفارش پیدا شد        '404':          description: سفارش پیدا نشد

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

• مستندات تعاملی؛
• Client SDK؛
• نمونه کد؛
• تست قرارداد؛
• Mock Server؛
• اعتبارسنجی ساختار API.

Webhook چیست و چه تفاوتی با API دارد؟

در API معمولی، Client باید از سرور سؤال کند:

آیا وضعیت سفارش تغییر کرده است؟

اگر این پرسش مرتب تکرار شود، Polling اتفاق می‌افتد.

Webhook برعکس عمل می‌کند. هنگامی که رویدادی رخ دهد، سرویس به آدرس ثبت‌شده درخواست ارسال می‌کند.

مثال:

POST https://client.example.com/webhooks/payment

بدنه:

{    "event": "payment.succeeded",    "order_id": 875,    "transaction_id": "TX-9082" }

کاربرد Webhook

• اعلام نتیجه پرداخت؛
• تغییر وضعیت ارسال؛
• ایجاد تیکت؛
• ثبت کاربر؛
• تکمیل پردازش فایل؛
• دریافت رویداد از سرویس ثالث.

نکات امنیتی Webhook

• امضای دیجیتال درخواست؛
• بررسی Timestamp؛
• جلوگیری از Replay Attack؛
• پاسخ سریع؛
• پردازش در Queue؛
• ثبت رویداد تکراری؛
• Idempotency؛
• Retry کنترل‌شده.

مزایای API در نرم‌افزار

یکپارچه‌سازی سیستم‌ها

API نرم‌افزارهای جداگانه را به یک جریان کاری متصل می‌کند.

استفاده مجدد از قابلیت‌ها

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

توسعه مستقل Front-end و Back-end

تیم‌ها می‌توانند بر اساس قرارداد مشخص، مستقل‌تر کار کنند.

توسعه اپلیکیشن‌های متعدد

یک Backend می‌تواند به وب، موبایل و دستگاه‌های دیگر سرویس دهد.

کاهش ورود تکراری اطلاعات

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

افزایش مقیاس‌پذیری

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

ایجاد اکوسیستم

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

خودکارسازی فرآیندها

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

محافظت از منطق داخلی

مصرف‌کننده فقط قابلیت‌های مجاز را می‌بیند و به دیتابیس یا سورس دسترسی ندارد.

چالش‌های استفاده از API

امنیت

هر Endpoint می‌تواند سطح حمله جدیدی ایجاد کند. احراز هویت به‌تنهایی کافی نیست و مجوزدهی در سطح داده نیز ضروری است.

وابستگی به سرویس ثالث

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

باید Timeout، Retry، Queue و راهکار جایگزین در نظر گرفته شوند.

تغییر نسخه

تغییر بدون مدیریت API می‌تواند Clientهای قدیمی را از کار بیندازد.

محدودیت مصرف

بعضی APIها هزینه یا Rate Limit دارند. نرم‌افزار باید مصرف را کنترل کند.

کیفیت مستندات

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

سازگاری داده

ممکن است دو سیستم تعریف متفاوتی از مشتری، سفارش یا وضعیت داشته باشند.

خطاهای شبکه

برخلاف فراخوانی داخلی، درخواست API ممکن است به‌دلیل قطعی، Timeout یا مشکل DNS ناموفق شود.

مانیتورینگ

بدون Metrics و Trace، پیدا کردن علت کندی در زنجیره چند سرویس دشوار است.

بهترین روش‌ها در طراحی و توسعه API

API را مانند یک محصول ببینید

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

ابتدا قرارداد را طراحی کنید

پیش از کدنویسی، مسیرها، Requestها، Responseها و خطاها مشخص شوند.

اصل کمترین دسترسی را رعایت کنید

هر Client و کاربر فقط مجوزهای موردنیاز را دریافت کند.

ورودی و خروجی را کنترل کنید

هیچ داده‌ای بدون اعتبارسنجی وارد یا بدون انتخاب صریح خارج نشود.

از استانداردهای HTTP درست استفاده کنید

معنای متدها، Status Codeها، Headerها و کش باید حفظ شود.

API را نسخه‌بندی کنید

برای تغییرات ناسازگار مسیر مهاجرت در نظر بگیرید.

مستندات را همراه کد به‌روز کنید

مستندات قدیمی گاهی از نبود مستندات خطرناک‌تر است.

تست خودکار بنویسید

تست‌های مهم:

• احراز هویت؛
• مجوز؛
• اعتبارسنجی؛
• ساختار پاسخ؛
• خطا؛
• Rate Limit؛
• قرارداد؛
• سناریوی یکپارچگی.

Observability داشته باشید

سه جزء مهم:

• Logs؛
• Metrics؛
• Traces.

باید بتوانید نرخ خطا، زمان پاسخ و Endpointهای پرترافیک را مشاهده کنید.

Sandbox ارائه دهید

برای APIهای عمومی یا Partner، محیط آزمایشی باعث کاهش ریسک توسعه می‌شود.

اطلاعات حساس را در URL قرار ندهید

URLها ممکن است در History، لاگ یا Proxy ذخیره شوند. Token و رمز نباید در Query String ارسال شوند.

CORS را محدود کنید

متد OPTIONS می‌تواند برای Preflight در CORS استفاده شود، اما سیاست CORS نباید بدون ضرورت برای تمام Originها باز باشد.

نقش API در معماری نرم‌افزارهای مدرن

API پایه ارتباط بسیاری از معماری‌های امروزی است.

معماری Headless

در معماری Headless، Backend محتوا و منطق را از طریق API ارائه می‌کند و Front-end مستقل است.

این رویکرد برای موارد زیر مناسب است:

• وب‌سایت؛
• موبایل؛
• کیوسک؛
• نمایشگر هوشمند؛
• چند کانال فروش.

میکروسرویس

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

برای مثال:

• سرویس کاربران؛
• سرویس سفارش؛
• سرویس پرداخت؛
• سرویس اعلان؛
• سرویس گزارش.

مزیت آن استقلال توسعه و استقرار است، اما پیچیدگی عملیاتی بیشتری دارد.

API Gateway

API Gateway در ورودی مجموعه سرویس‌ها قرار می‌گیرد و می‌تواند این وظایف را انجام دهد:

• مسیریابی؛
• احراز هویت؛
• Rate Limiting؛
• ثبت لاگ؛
• تبدیل درخواست؛
• کش؛
• تجمیع پاسخ؛
• مدیریت نسخه.

Event-Driven Architecture

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

این روش برای کاهش وابستگی مستقیم مفید است، اما مدیریت سازگاری داده و رویدادهای تکراری اهمیت دارد.

آیا هر نرم‌افزاری به API نیاز دارد؟

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

اما API در این شرایط معمولاً ارزشمند است:

• اپلیکیشن موبایل وجود دارد؛
• Front-end از Backend جداست؛
• اتصال به نرم‌افزار دیگر لازم است؛
• چند کانال کاربری وجود دارد؛
• شرکای تجاری به داده نیاز دارند؛
• توسعه آینده پیش‌بینی شده است؛
• معماری سرویس‌گرا استفاده می‌شود.

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

هزینه طراحی API به چه عواملی بستگی دارد؟

هزینه صرفاً بر اساس تعداد Endpointها تعیین نمی‌شود.

عوامل اصلی عبارت‌اند از:

• پیچیدگی منطق کسب‌وکار؛
• تعداد منابع؛
• روش احراز هویت؛
• سطح دسترسی؛
• اتصال‌های ثالث؛
• حجم داده؛
• نیاز به Webhook؛
• مستندسازی؛
• تست؛
• امنیت؛
• Rate Limiting؛
• مانیتورینگ؛
• محیط Sandbox؛
• SLA؛
• پشتیبانی نسخه‌ها.

برای مثال، Endpoint دریافت محصول ساده‌تر از API تسویه مالی با کنترل تکرار، امضای دیجیتال و ثبت تاریخچه است.

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

پرسش‌های متداول درباره API

۱. API مخفف چیست؟

API مخفف Application Programming Interface و به‌معنای رابط برنامه‌نویسی کاربردی است.

۲. API چه کاری انجام می‌دهد؟

API به برنامه‌ها اجازه می‌دهد داده یا قابلیت مشخصی را از یکدیگر دریافت و استفاده کنند.

۳. آیا API همان دیتابیس است؟

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

۴. آیا API فقط برای وب استفاده می‌شود؟

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

۵. REST API چیست؟

یک API مبتنی بر اصول REST است که معمولاً منابع را با URL و عملیات را با متدهای HTTP مدل می‌کند.

۶. تفاوت API و Web Service چیست؟

Web Service نوعی API شبکه‌ای است. API مفهوم گسترده‌تری دارد و الزاماً مبتنی بر وب نیست.

۷. JSON چیست؟

JSON قالبی متنی برای تبادل داده است که در APIها بسیار رایج است.

۸. Endpoint چیست؟

Endpoint یک مسیر مشخص از API است که قابلیت یا منبع خاصی را ارائه می‌دهد.

۹. API Key چیست؟

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

۱۰. تفاوت 401 و 403 چیست؟

401 معمولاً یعنی احراز هویت انجام نشده یا نامعتبر است. 403 یعنی هویت مشخص است اما مجوز عملیات وجود ندارد.

۱۱. آیا API امن است؟

API در صورت طراحی و پیاده‌سازی صحیح می‌تواند امن باشد، اما نیازمند احراز هویت، مجوزدهی، اعتبارسنجی، HTTPS و پایش است.

۱۲. آیا می‌توان API را با Laravel ساخت؟

بله. Laravel امکاناتی برای Route، Validation، Resource، Authentication، Rate Limiting، Queue و تست API دارد.

۱۳. Swagger چیست؟

Swagger نام مجموعه‌ای از ابزارها برای طراحی، نمایش و آزمایش APIهای مبتنی بر OpenAPI است. OpenAPI خود استاندارد توصیف API محسوب می‌شود.

۱۴. Webhook چیست؟

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

۱۵. Rate Limit چیست؟

محدودیت تعداد درخواست‌هایی است که یک کاربر یا Client در بازه زمانی مشخص می‌تواند ارسال کند.

۱۶. آیا API باید نسخه‌بندی شود؟

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

۱۷. GraphQL بهتر است یا REST؟

هیچ‌کدام همیشه بهتر نیستند. انتخاب به نوع داده، تعداد Clientها، نیازهای Query و توان تیم بستگی دارد.

۱۸. آیا اپلیکیشن موبایل بدون API کار می‌کند؟

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

۱۹. چگونه API را تست کنیم؟

با تست خودکار، ابزارهای ارسال Request، تست قرارداد، تست امنیت و محیط Sandbox.

۲۰. آیا API عمومی باید رایگان باشد؟

خیر. API می‌تواند رایگان، محدود، اشتراکی یا مبتنی بر میزان مصرف باشد.

جمع‌بندی

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

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

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

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

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

برای طراحی و توسعه API مشاوره بگیرید

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

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

منابع رسمی

• استاندارد رسمی معنای پیام‌ها و متدهای HTTP در RFC 9110
• راهنمای جامع پروتکل HTTP در MDN
• راهنمای متدهای درخواست HTTP در MDN
• راهنمای پیام‌های Request و Response در MDN
• مشخصات رسمی OpenAPI نسخه 3.2
• رجیستری رسمی مشخصات OpenAPI Initiative
• فهرست رسمی ریسک‌های امنیتی OWASP API Security Top 10
• صفحه رسمی پروژه امنیت API در OWASP
• استاندارد رسمی کش HTTP در RFC 9111