پاسخ ۲۰۰ گرفتید،ولی جواب درست بود؟
یک API میتواند کد ۲۰۰ برگرداند و در همان حال لیست خالی، خطای داخلی در بدنه یا دادهٔ قدیمی بدهد. چکاو علاوه بر در دسترس بودن، خود محتوای پاسخ را بررسی میکند و اگر آنچه انتظار دارید در پاسخ نبود، همان را قطعی حساب میکند.
پلن رایگان: ۳ مانیتور و یک نقطهٔ سنجش · ۱۴ روز بستهٔ حرفهای رایگان
چه چیزی از پاسخ بررسی میشود
هر شرطی که تعریف کنید، اگر برقرار نباشد نتیجه خطا ثبت میشود.
کد وضعیت
کدهای موفق مورد انتظار را تعیین میکنید؛ هر کد دیگری خطا حساب میشود.
زمان پاسخ
سقفی برای زمان پاسخ بگذارید؛ پاسخ کندتر از آن خطا محسوب میشود.
محتوای پاسخ
بررسی اینکه متنی در پاسخ هست، نیست، دقیقاً برابر است یا با یک الگو تطبیق دارد.
بررسی دقیق فیلدهای JSON
بهجای جستوجوی متنی در کل بدنه، مستقیم سراغ همان فیلد میروید.
مسیر فیلد
مسیرهایی مثل $.status یا $.data.items[0].id پشتیبانی میشوند؛ هم دسترسی نقطهای، هم اندیس آرایه.
چهار حالت بررسی
وجود داشتن فیلد، برابر بودن با مقدار، برابر نبودن، یا شامل بودن یک مقدار.
مثال واقعی
شرط «$.status برابر ok» یعنی اگر سرویس ۲۰۰ برگرداند ولی وضعیت داخلیاش degraded شده باشد، رخداد باز میشود.
پاسخ غیر JSON
اگر بدنه JSON معتبر نباشد یا مسیر پیدا نشود، دلیل خطا دقیقاً همین را میگوید، نه یک پیام مبهم.
درخواستی که میفرستیم
همانطور که سرویس شما انتظار دارد، نه یک درخواست عمومی.
GET یا POST
برای POST میتوانید بدنه و نوع محتوای آن را تعیین کنید.
هدرهای دلخواه
هدرهایی که API شما لازم دارد؛ مقدارشان هرگز در نتیجه یا شواهد خطا نمایش داده نمیشود.
توکن احراز هویت
توکن Bearer ذخیره میشود و هرگز از API برنمیگردد؛ فقط میبینید که تنظیم شده است.
کنترل TLS و ریدایرکت
دنبالکردن ریدایرکت و بررسی گواهی را میتوانید خاموش کنید — برای محیطهایی که گواهی داخلی دارند.
وقتی خطا میدهد، چه چیزی دستتان را میگیرد
هدف این است که لازم نباشد خودتان دوباره بازتولیدش کنید.
دلیل مشخص خطا
مثلاً «مقدار فیلد JSON مطابق نبود» یا «کد وضعیت غیرمنتظره»، نه فقط «ناموفق».
بخشی از بدنهٔ پاسخ
برای پاسخهای متنی، تکهای از بدنه در لحظهٔ خطا نگه داشته میشود.
هدرهای امن پاسخ
فهرست محدودی از هدرها مثل نوع محتوا و شناسهٔ درخواست؛ هدرهای حساس هرگز ذخیره نمیشوند.
نتیجهٔ هر منطقه
میبینید مشکل از یک نقطهٔ سنجش بوده یا همهٔ آنها همین را دیدهاند.
مرزهای این ابزار
بررسی چندمرحلهای نداریم
هر مانیتور یک درخواست میفرستد. سناریوی «ورود، بعد گرفتن توکن، بعد فراخوانی» فعلاً پشتیبانی نمیشود.
بررسی محتوا از بستهٔ آغازین است
در پلن رایگان مانیتور API میسازید و کد وضعیت و زمان پاسخ را میبینید؛ هدر و بدنهٔ دلخواه، توکن، JSONPath و تطبیق پیشرفتهٔ محتوا از بستهٔ آغازین فعال میشوند.
درخواست تغییردهنده نفرستید
مانیتور همان درخواست را مرتب تکرار میکند؛ روی endpointای بگذارید که خواندنی باشد.
از بیرون میبینیم
چکاو مثل یک مصرفکنندهٔ API به سرویس شما وصل میشود؛ لاگ یا متریک داخلی سرور را نمیخواند.
یک endpoint واقعی را امتحان کنید
یک مانیتور API بسازید، شرط محتوای پاسخ را تعریف کنید و ببینید نتیجه و شواهد خطا چه شکلی است.
ساخت حساب رایگان