ניטור API

מדוע API זקוק לניטור ייחודי

API זה לא סתם עמוד ב- /api/. זהו חוזה. שיטת ה-HTTP משנה – GET לעומת POST מחליפים את הסמנטיקה. הכותרות נושאות איתן אימות, שיחות ניהול תוכן, מפתחות לאידמפוטנטיות. גוף הבקשה הוא קלט. קוד התשובה משמעותי (401 לעומת 403 לעומת 422 – כל אחד אומר סיפור אחר). גוף התשובה הוא במבנה – נתיבי JSON שעליהם מסתמכים האינטגרטורים. בדיקת uptime רגילה, הפוגעת רק ב-URL ב-GET, מפספסת את רוב הדרכים בהן API עלול ליפול: JSON לא תקני שמחזיר עדיין 200, נקודת קצה אימות שמקבלת נתונים שגויים, webhook עם סכמת payload פגומה, endpoint שמחזיר 200 אבל עם "status": "error" בפנים.

ניטור API פותר זאת בכך שהוא מעניק לך שליטה בכל חלק מהבקשה ובכל שלב באימות התשובה. אתה מגדיר בדיוק את הקריאה שאינטגרטוריך מבצעים – אותה שיטה, אותם כותרות, אותו גוף, אותו אימות – ומגדיר בדיוק מהו הצלחה – קודים מדויקים, ערכים בנתיבי JSON, סף זמן תגובה, גבולות גודל.

הגדרת הבקשה

לכל מוניטור API ב-DiagnoSEO Uptime Monitoring תוכל להגדיר:

• שיטת HTTP: GET, POST, PUT, PATCH, DELETE, HEAD. בחר את זו שהאינטגרטורים שלך משתמשים בה.
• כותרות מותאמות אישית: כאובייקט JSON, לדוג': {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. סטנדרטי לבדיקת OAuth, JWT, מפתחות API, ניהול תוכן.
• גוף הבקשה: כל מחרוזת – JSON, XML, מקודדת כטופס, טקסט רגיל. נשלח ב-POST/PUT/PATCH/DELETE.
• Basic auth: שם משתמש וסיסמה, אם הקצה מוגן כך.
• קודי סטטוס צפויים: רשימה או טווח. ברירת מחדל 200–399, אך ניתן לצמצם לקוד בודד (למשל בדיוק 201 ל-endpoint יצירה) או לאפשר קודים מסוימים (למשל 200,202,204).

הבדיקה עוקבת אחרי מקסימום 5 הפניות (redirects), מפרשת gzip, מנתחת Content-Type כדי לזהות JSON. כל בדיקה רושמת את הקוד בפועל, זמן התגובה, הגודל וכל שגיאה אפשרית. סדרה של תקלות (ניתן להגדיר, ברירת מחדל 2) גורמת לאירוע.

אישושי JSON path

קודי סטטוס לבדם לא תמיד מספיקים. נקודת קצה 'בריאות' (health) יכולה להחזיר 200 עם גוף {"status": "degraded", "db": "down"} – עדיין 200, אבל לגמרי תרצה לדעת. API מחירים יכול להחזיר 200 עם גוף שבו data.price ירד ל-null. API חיפוש יכול להחזיר 200 עם results: [] כי האינדקס נפל.

למקרים כאלה הגדר אישוש JSON path. הגדר את הנתיב (למשל data.status או health.checks.db) ואת הערך הצפוי (לדוג' healthy, true או מספר מסוים). בכל בדיקה התשובה מפוענחת כ-JSON והערך בנתיב נבדק. אי התאמה מסיימת את הבדיקה בכשל, בלי קשר לסטטוס HTTP.

תחביר הנתיב הוא נקודה וסוגריים: data.items[0].id עובד, גם users.john.email. הערך לאישוש מושווה כמחרוזת, כך ש-"true" תואם ל-true בוליאני, ומספרים תואמים גם כמחרוזת וגם כמספר.

דפוסי אימות

שני סגנונות האימות הנפוצים עובדים מיידית. עבור טוקנים מסוג Bearer (OAuth, JWT, מפתחות API) השתמש בשדה headers: {"Authorization": "Bearer eyJhbGciOi..."}. הטוקן נשמר בהגדרות המוניטור ונשלח בכל בדיקה. עבור basic auth השתמש בשדות הייעודיים של שם משתמש/סיסמה – נשמרים ומוזנים אוטומטית לכותרת סטנדרטית.

אם האימות דורש חתימה לכל בקשה או ריענון טוקן, זה מסובך יותר. שני דפוסים סבירים: (1) הגדר טוקן של חשבון שירות ארוך חיים במיוחד לניטור, או (2) הוסף נקודת קצה health לא מוגנת שמציגה את מצב הקצה המוגן האמיתי ופתח עליה ניטור. לרוב ה-APIים המודרניים יש אפשרות זו אוטומטית.

דפוסים מומלצים

• מוניטור אחד לכל endpoint קריטי. אין צורך לבדוק כל אחד – בחר 5–10, שכשל בהם יגרום לנזק אמיתי.
• השתמש בקודים מדויקים. טווח ברירת המחדל 200–399 רחב מדי ל-API. נקודת יצירה צריכה להחזיר בדיוק 201; אידמפוטנטית בדיוק 200; נקודת התחברות בדיוק 200 (הצלחה) או 401 (כשל "הגיוני" – לא 500).
• שלב סטטוס עם אישוש JSON. יחד הם תופסים רגרסיות גם בשכבת התעבורה וגם בתוכן. סטטוס לבד לא תופס שגיאות תוכן; אישוש JSON בלבד שברירי במעבר הפניות.
• הגדר סף זמן תגובה. נסיגה בביצועי API היא אינדיקציה מוקדמת לבעיות בתלות. מוניטור עם rt_threshold_ms = 800 מזהיר ש-API מאט לפני שהוא נופל.
• שמור על גוף קטן. הבדיקה מתבצעת כל דקה – גוף גדול מבזבז רוחב פס משני הצדדים. payload ייצוגי אך מינימלי מספיק בהחלט.

שילוב עם סוגי ניטור נוספים

לכל endpoint של API, ניטור API בודק שהקריאה עובדת. ניטור ping או פורט נפרד בודק שה-host פעיל. בדיקת SSL/דומיין על אותו host תופסת בעיות אישור ותוקף. תת-ניטור DNS בודק שינויים ברשומות שעשויים להצביע על חטיפה. יחד, ארבעה מוניטורים ל-API נותנים תמונה מלאה עם מינימום חפיפה.

הגדרה

פתח את הכלי, לחץ "הוסף מוניטור", בחר בסוג "API". הדבק את ה-URL. פתח את ההגדרות המתקדמות. בחר שיטה, הדבק כותרות כ-JSON, הדבק גוף במידת הצורך, הגדר basic auth במידת הצורך, הכנס את הקודים הצפויים (למשל 200 או 200,201). הוסף אישוש JSON path אם יש צורך. קבע מרווח וסף אימות. שמור. מהמחזור הבא המוניטור יקרא ל-API שלך בדיוק כמו שאינטגרטור היה עושה, יאמת את התגובה ויתריע בשנייה של רגרסיה.

שאלות נפוצות

• אילו שיטות HTTP ניתן להשתמש בהן לניטור API?

  GET, POST, PUT, DELETE, PATCH ו-HEAD. קבע את השיטה לכל מוניטור – עבור endpoint-ים שעושים כתיבה (POST/PUT/PATCH) גוף הבקשה גם הוא ניתן להגדרה כמחרוזת JSON או נתוני טופס.

• איך פועלים אישושי JSON?

  אתה מזין נתיב JSON (למשל data.status או results[0].id) ואת הערך הצפוי. המוניטור אוסף את התשובה, מפרש ל-JSON, שולף את הנתיב ומשווה לערך שהגדרת. אם אין התאמה, הבדיקה נכשלת עם השגיאה "assertion failed" שמציגה את הערך בפועל.

• האם ניתן לשלוח כותרות אימות?

  כן. כותרות HTTP מותאמות אישית ניתנות להגדרה לכל מוניטור – Authorization, מפתחות API, content-type, כל מה שנדרש. ערכי הכותרות מוצפנים במנוחה במסד הנתונים. עבור Basic Auth יש שדה ייעודי לשם משתמש/סיסמה שחותם את הבקשה אוטומטית.

• מה אם ה-API שלי מחזיר 200 עם payload שגיאה?

  תבנית נפוצה: API מחזיר HTTP 200 אבל בגוף כתוב {"status":"error"}. ניטור uptime נאיבי חושב שזה תקין. השתמש באישוש JSON status == "ok" כדי לתפוס את זה — האישוש ייכשל והמוניטור ידווח DOWN למרות ש-HTTP אומר 200.

• איך להתמודד עם API שמוגבל ב-rate limit?

  הגדר את מרווח הבדיקות בהתאם למגבלה (למשל מרווח של 5 דקות אם ה-API מאפשר 12 קריאות לשעה). כל בדיקה נספרת כקריאה אחת ל-API לאזור. בדיקות Multi-region מכפילות את מספר הקריאות — בחר single-region אם ל-API שלך יש הגבלות מחמירות.