ATP - بررسی آمادگی سرویس (GET /api/ready/)

Endpoint

GET /api/ready/

هدف آزمون

بررسی دسترسی به PostgreSQL و Redis.

شرایط آزمون

• سرویس core-api در حال اجرا باشد
• PostgreSQL و Redis در دسترس باشند

فرآیند آزمون

1. ارسال درخواست GET به /api/ready/
2. دریافت پاسخ HTTP
3. بررسی کد وضعیت و بدنه JSON

معرفی ویژگی

این endpoint عملیات «بررسی آمادگی سرویس» را در API Patent Genie انجام می‌دهد.

• وابستگی‌ها: فقط PostgreSQL و Redis
• RabbitMQ خارج از scope: قطع موقت broker باعث 503 این endpoint نمی‌شود؛ messaging را از /api/messaging/health/ ببینید
• ورودی معتبر: بدون پارامتر
• بدون auth: عمومی (probe)

سناریوی آزمون

سناریو 1: مسیر موفق

1. ارسال GET /api/ready/
2. دریافت پاسخ موفق
3. بررسی ساختار پاسخ

سناریو 2: خطا - درخواست نامعتبر

1. ارسال درخواست با داده یا شناسه نامعتبر
2. دریافت کد خطای 4xx
3. بررسی پیام خطای استاندارد API

سناریو 3: خطا — PostgreSQL در دسترس نیست

1. قطع اتصال PostgreSQL در محیط تست
2. ارسال GET /api/ready/
3. دریافت کد 503
4. بررسی checks.database برابر "error"

سناریو 4: خطا — Redis در دسترس نیست

1. قطع اتصال Redis در محیط تست
2. ارسال GET /api/ready/
3. دریافت کد 503
4. بررسی checks.redis برابر "error"

قالب API

Swagger

get:
  summary: بررسی آمادگی سرویس
  responses:
    200:
      description: عملیات موفق
    401:
      description: احراز هویت نامعتبر یا ناقص

نمونه ورودی

curl -X GET "http://localhost:8000/api/ready/" \
  -H "Content-Type: application/json"

نمونه خروجی

{
  "status": "ok",
  "checks": {"database": "ok", "redis": "ok"}
}

Status Codes

• 200: همه وابستگی‌ها سالم
• 503: حداقل یک وابستگی خطا دارد

نتیجه مورد انتظار

در حالت سالم checks.database و checks.redis برابر ok هستند.

روال صحت‌سنجی

1. بررسی کد وضعیت HTTP
2. بررسی فیلد success در بدنه
3. بررسی عدم افشای داده حساس

توضیحات

• برای load balancer readiness probe
• messaging/RabbitMQ را با /api/messaging/health/ جداگانه پروب کنید
• اوت‌باکس برای جذب outage کوتاه broker طراحی شده است