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

وقتی دربارهٔ API صحبت می‌کنیم، خیلی راحت فراموش می‌کنیم که این موضوع آن‌قدرها هم دقیق و یکسان برای همه تعریف نشده است. مثل هر موضوع پیچیدهٔ دیگری، وقتی سؤال‌های ساده می‌پرسیم، مشکلات شروع می‌شوند. مثال معروف کشتی تسئوس (Ship of Theseus) دقیقاً همین است: وقتی قطعات یک شیء یکی‌یکی عوض می‌شوند، از کی می‌شود گفت دیگر همان شیء قبلی نیست؟ وقتی ۵۰ درصد قطعات عوض شد هنوز همان کشتی است؟ ۷۵ درصد چطور؟

شاید عجیب به نظر برسد، اما در اجلاس API آستین ۲۰۲۴، راب دیکینسون، معاون مهندسی شرکت Graylog، سؤالی فلسفی از همین نوع مطرح کرد که پیامدهای واقعی و جدی دارد:

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

پاسخ این سؤال به‌طرز شگفت‌آوری پیچیده‌تر از آن چیزی است که فکر می‌کنید.

در ادامه به پاسخ دیکینسون نگاه می‌کنیم، روش‌های منطقی شمارش API را بررسی می‌کنیم و توضیح می‌دهیم چرا این تمایز برای کشف‌پذیری (discoverability) و ساخت فهرست API که بتواند امنیت و ریسک را در مقیاس بزرگ مدیریت کند، حیاتی است.

چرا کشف API مهم است؟

قبل از هر چیز باید بپرسیم: اصلاً چرا باید اهمیت بدهیم؟

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

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

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

دیکینسون می‌گوید هدف خیلی ساده است: باید بتوانیم بگوییم: «ما در حال حاضر X عدد API داریم که Y عدد از آن‌ها جدید هستند و Z عدد نیاز به توجه فوری دارند.»

اما مشکل اصلی همین‌جاست: اصلاً API چیست؟

واقعاً یک API چیست؟

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

دیکینسون چند دلیل برای این پیچیدگی می‌آورد:

• بهترین روش‌های API هنوز به‌خوبی شناخته و پذیرفته نشده‌اند.
• تغییر تعداد endpointها، ماهیت سرویس‌ها یا داخلی/خارجی بودن آن‌ها می‌تواند شمارش کلی را به‌کلی عوض کند.
• APIها برخلاف وب‌سایت یا ایمیل «تاریک» هستند — برای استفاده از آن‌ها دانش فنی قابل‌توجهی لازم است.
• سرعت تغییر بالا و فرهنگ‌های متفاوت فنی باعث شده حتی برای متخصصان هم تعریف API مبهم باشد و برای افراد عادی تقریباً کاملاً نامفهوم.

مثال واقعی از مشکل شمارش API

سه درخواست فرضی زیر را ببینید:

REQUEST A
POST coinbroker.io/user
{
  "first_name": "Rob",
  "last_name": "Dickinson",
  "email": "rob@resurface.io"
}

REQUEST B
GET coinbroker.io/quote
{
  "Account_token": "4b86cd3f-ccaf-445b-b099",
  "Amount_usd": "6",
  "coin_type": "BTC"
}

REQUEST C
POST coinbroker.io/order
{
  "Account_token": "4b86cd3f-ccaf-445b-b099",
  "Quote_token": "552cd9da-2ff4-4dfe-b2eb"
}

سؤال: اینجا چند تا API داریم؟

بسیاری می‌گویند «سه تا» — و شاید درست هم بگویند. اما پاسخ «یک» یا «دو» هم می‌تواند درست باشد!

• آیا هر درخواست یک API جدا است؟
• آیا چون داده‌های مشابهی دارند، یک API هستند؟
• آیا مسیر (path) تعیین‌کننده است؟
• اگر این‌ها میکروسرویس باشند، هر میکروسرویس یک API است یا کل سرویس یک API محسوب می‌شود؟

این دقیقاً همان مشکلی است که دیکینسون می‌خواهد نشان دهد: هیچ پاسخ قطعی و کاملی وجود ندارد، اما همهٔ این پاسخ‌ها می‌توانند درست باشند.

روش‌های منطقی شمارش API

چند راه حل منطقی وجود دارد:

• شمارش FQDN (دامنهٔ کامل) → ایده‌ای از تعداد سرویس‌ها می‌دهد.
• شمارش routeها یا ترکیب FQDN + route.
• تفکیک APIهای داخلی و خارجی.
• APIهای منسوخ‌شده (deprecated) که هنوز کار می‌کنند اما قابلیتشان به API دیگری منتقل شده.

اما همهٔ این‌ها مشکلات جدیدی ایجاد می‌کنند.

راه‌حل پیشنهادی دیکینسون: شمارش بر اساس مشخصه (specification) یعنی تعداد APIها را مشخصهٔ OpenAPI (یا هر مشخصهٔ دیگر) تعیین کند، نه تعریف ذهنی ما.

مشکل جدید: وضعیت تغییر (State of Change)

اما این روش هم مشکل جدیدی به وجود می‌آورد: چطور APIهایی را بشماریم که در مشخصه نیستند؟ (مثل APIهای یاغی یا زامبی)

راه‌حل دیکینسون: دسته‌بندی بر اساس وضعیت چرخهٔ حیات:

این روش یک شمارش «متن‌محور» ایجاد می‌کند که به جای عدد خام، وضعیت واقعی APIها را نشان می‌دهد.

و حالا ریسک چطور؟

فقط دانستن تعداد و وضعیت کافی نیست. باید ریسک هم تخصیص دهیم.

معیارهای مفید برای محاسبهٔ ریسک:

• فعالیت کاربران
• ترافیک شبکه
• تغییرات اخیر در API
• داده‌های درخواست و پاسخ (پاسخ معمولاً جایی است که نشت داده رخ می‌دهد)

با ترکیب مشخصه + نظارت زمان اجرا (runtime monitoring) + لاگ‌گیری، می‌توانیم تصویر واقعی از سطح حمله و ریسک بسازیم.

مراحل کشف API (مدل پیشنهادی دیکینسون)

1. Walk (راه رفتن) ساخت فهرست API با استفاده از مشخصه تعریف داخلی اینکه چه چیزی یک API محسوب می‌شود مستندسازی + نظارت زمان اجرا
2. Run (دویدن) ردیابی تغییرات در فهرست دسته‌بندی APIها بر اساس چرخهٔ حیات افزودن زمینهٔ کاربری واقعی
3. Rocket ship (موشک) ردیابی تغییرات در معیارهای ریسک محاسبهٔ ریسک نسبی رویکرد مبتنی بر معیار واقعی به امنیت

نتیجه‌گیری

برای بسیاری — به‌ویژه طرفداران مشخصهٔ API — این حرف‌ها بدیهی به نظر می‌رسد. اما برای خیلی‌های دیگر، یک کشف بزرگ است.

مهم‌ترین پیام دیکینسون این است: تعریف دقیق API کمتر مهم است تا اینکه این تعریف را چگونه به اشتراک می‌گذاریم و اندازه‌گیری می‌کنیم.

امنیت یعنی داشتن معیار. اگر نتوانیم بشماریم چه داریم، نمی‌توانیم بفهمیم چقدر امن هستیم.

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