چک‌های چندمرحله‌ای API: مانیتورینگ جریان‌های ورود و توکن.

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

نکته‌های کلیدی

• هر مرحله یه درخواسته؛ مقدارهایی که از یه پاسخ استخراج می‌شن به مرحله‌ی بعد داده می‌شن.
• جریان معمول: احراز هویت، صدا زدن یه endpoint محافظت‌شده، تأیید یه endpoint جزئیات.
• روی همه‌ی مرحله‌ها شرط بذارید، نه فقط آخری، تا خرابی‌ها دقیق مشخص بشن.
• اطلاعات ورود رو به‌شکل secret نگه دارید و از یه حساب تست با کمترین دسترسی استفاده کنید.
• جریان‌ها رو کوتاه و فقط‌خواندنی نگه دارید، یا هر چیزی که می‌سازن رو پاک کنید.

یه جریان معمول

Step 1  POST /api/auth/login        { "username": "monitor", "password": "***" }
        expect 200, extract  access_token = $.token
Step 2  GET  /api/orders?limit=1    Authorization: Bearer {access_token}
        expect 200, expect $.items.length > 0, extract order_id = $.items[0].id
Step 3  GET  /api/orders/{order_id} Authorization: Bearer {access_token}
        expect 200, expect $.id == {order_id}

اگه مرحله‌ی ۱ شکست بخوره، احراز هویت خرابه. اگه مرحله‌ی ۲ با 401 شکست بخوره، توکن صادر می‌شه ولی پذیرفته نمی‌شه؛ شاید چرخش کلید اشتباه انجام شده. اگه فقط مرحله‌ی ۳ شکست بخوره، مشکل از endpoint جزئیات یا کوئری دیتابیسشه.

استخراج مقدارها

بیشتر ابزارها از عبارت‌هایی شبیه JSONPath برای بیرون کشیدن مقدار از پاسخ استفاده می‌کنن:

مقدارها می‌تونن از هدرهای پاسخ (مثلاً هدر Location بعد از ساختن یه رکورد) یا کوکی‌ها برای ورودهای مبتنی بر session هم بیان.

شرط‌هایی که ارزش اضافه کردن دارن

• کد وضعیت در همه‌ی مرحله‌ها.
• زمان پاسخ هر مرحله؛ ورود کند حتی وقتی موفقه ارزش دونستن داره.
• محتوای بدنه؛ لیست غیرخالی، شناسه‌های مورد انتظار، فیلد status با مقدار ok.
• هدرها؛ Content-Type: application/json و هدرهای کش هر جا مهمن.

امنیت اطلاعات ورود مانیتورینگ

• یه کاربر مانیتورینگ اختصاصی با دسترسی فقط‌خواندنی و بدون داده‌ی شخصی بسازید.
• رمز یا کلید API اون رو در فیلدهای secret مانیتور نگه دارید؛ نباید در لاگ‌ها یا هشدارها دیده بشه.
• کلید API یا جریان client-credentials رو به رمز شخصی ترجیح بدید.
• اطلاعات ورود رو مثل هر secret دیگه‌ای بچرخونید و وقتی عوضش کردید، مانیتور رو به‌روز کنید.

دوری از اثرهای جانبی

جریان‌های چندمرحله‌ای وسوسه‌تون می‌کنن «ثبت سفارش» رو هم تست کنید. اگه مجبورید نوشتن رو تست کنید:

• از محیط sandbox یا یه tenant تستی استفاده کنید،
• رکوردهای ساخته‌شده رو با یه نشونه‌ی واضح علامت بزنید و در یه مرحله‌ی آخر پاکشون کنید،
• هیچ‌وقت پرداخت، پیامک یا ایمیل واقعی راه نندازید.

راه‌اندازی در noc724

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

پرسش‌های پرتکرار

• یه جریان چند مرحله باید داشته باشه؟

  +

  به اندازه‌ای که ثابت کنه جریان کار می‌کنه؛ معمولاً دو تا چهار. هر مرحله‌ی اضافه یه جای دیگه است که تغییرات بی‌خطر می‌تونن چک رو خراب کنن.

• توکن‌ها بین چک‌ها منقضی نمی‌شن؟

  +

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

• می‌شه APIهای محافظت‌شده با OAuth رو مانیتور کرد؟

  +

  بله. یه درخواست client-credentials رو مرحله‌ی اول بذارید تا توکن دسترسی بگیرید و بعد API رو با اون صدا بزنید.