🧪 مفهوم و کاربرد API Mocking & Virtualization

خیلی از سردردها از نداشتن محیط اجرای مناسب نشأت می‌گیره؛ و خیلی از محیط خوب نداشتن‌ها از ترس پیچیده یا زمان‌بر بودنِ پیاده‌سازی. از طرف دیگه خیلی از integration ها با آسودگی و سرعت پیش نمی‌رن؛ چون API سیستمِ دیگه، شفاف نیست، یا محیط test نداره.

شنیدن جمله "منتظرم API شون آماده شه!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، منتظر نمی‌مونن، mock می‌کنن، یا قبل از توسعه API واقعی، اول API Spec رو می‌نویسن و در اختیار تیم‌های دیگه قرار می‌دن. اگر هم خیلی بالغ باشن که به جز API Spec ساز و کارkey management برای محیط‌های dev/test/stage/production رو هم محیا و ارائه می‌کنن.

بیاین در گام اول بیخیالِ میزان بلوغ تیم مقابل بشیم و خودمون رفتارهای بالغانه در تیم داشته باشیم:

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

🚦 چرا مهمه؟
- کاهش وابستگی‌ها: تیم‌ها می‌تونن موازی کار کنن.
- بهبود تست و استیجینگ: سناریوهای خطا و پاسخ‌های خاص قابل بازسازی هستن.
- تکرارپذیری: تست‌ها بدون وابستگی به داده‌های زنده انجام می‌شن.
- پیشرفت بدون صبر: تا backend آماده بشه، frontend یا consumer هم رشد می‌کنه.

🧰 ابزارها

۱: ابزار Mockoon
رایگانه، دسکتاپ اپلیکیشن با رابط گرافیکی خوب است (نسخه مک و ویندوز داره) نسخه CLI هم داره.

۲: ابزار WireMock
یکی از بهترین ابزارها بود تا اینکه نسخه رایگان و پولی منتشر کرد! هنوز هم از نظر قابلیت‌ها ابزار خیلی خوبیه و مثلا rule-based mock، یا fault simulation رو خیلی خوب پشتیبانی می‌کنه.

۳: ابزار Microcks
هنوز به بلوغ WireMock نرسیده ولی ابزار خیلی خوبیه، یه UI وب ساده هم داره ولی هنوز کامل نیست (مثلا اینکه بتونید با UI انواع payloadها رو تعریف کنید یا chain بسازید رو نداره.

۴: ابزار (سرویس) Postman Mock Server
خب پست‌من دیگه برای همه شناخته شده است، ولی سرویس‌ها انترپرایزش نیاز به لایسنس داره چون نسخه رایگان همین mock server فقط ۳ کاربر رو پشتیبانی می‌کنه و محدودیت‌های زیادی داره.

چجوری payload رو محیا کنیم؟

۱. استخراج از مستندات موجود
اگر تیم backend مستندات OpenAPI/Swagger داره، راحت‌ترین راهه:

curl https://api.company.com/openapi.json -o spec.json
mockoon-cli import --data spec.json

حتی اگر schema دقیق نباشه، حداقل مسیرها و ساختار پایه آماده‌ست.

۲. Sniff کردن درخواست‌ها در زمان کار
اگه endpointها در محیط تست یا staging یا جایی که بتونین حداقل یک بار صداشون کنین در دسترس هستن؛ ولی مستندات ندارن:
از Fiddler, Charles, یا mitmproxy یا ابزارهای مشابه استفاده کنید برای کپی کردن و استخراج درخواست‌ها و پاسخ‌ها. بعد اون‌ها رو به JSON تبدیل و برای mock استفاده کنین.
(یه snapshot واقعی از تعامل سیستم‌هاست)

۳. تولید خودکار مدل از JSON
وقتی چند تا نمونه JSON داری ولی model نه:
ابزارهای زیادی از جمله خود IDE های رایج سریع JSON رو به تایپ تبدیل می‌کنن و این کمک می‌کنه تا schema بسازین و بر اساس اون mock بنویسین.

۴. ساخت چند سناریو
فقط happy path رو mock نکن! یعنی اینکه همه چیز خیلی خوب و باب طبع باشه کافی نیست؛ سناریوهای مختلف مثل انواع خطاهای کد 4xx یا 5xx یا کندی‌ها یا تام‌اوت یا... رو هم در mock‌هات بسازین.

جمع‌بندی
فراموش نکنین که Mocking فقط یه کار “موقتی” نیست، یه مهارت توسعه‌ی تیمیه برای استقلال، سرعت و کیفیت. وقتی payloadها درست جمع‌آوری بشن، Mocking تبدیل میشه به پلی بین توسعه، تست و واقعیت سیستم.

💬 اگر موضوعاتی مثل Governance and Standardization یا API-First یا API Monitoring براتون جذاب بود حتمن بگید تا کمی در موردشون گپ بزنیم.