בדיקת וובהוקים
איך בודקים צרכן של וובהוקים בלי לחכות לתעבורה אמיתית.
בקצרה
- לכל חשבון יש פרויקט בדיקה. שום דבר שמנסים בו לא נוגע בתעבורה החיה.
- אפשר לשלוח אירוע בדיקה ליעד (endpoint) אחד בלי לפרסם לכולם.
- פרויקט בדיקה יכול להצביע על HTTP רגיל, ופרויקט חי לא יכול.
משתמשים בפרויקט הבדיקה
כל חשבון נפתח עם שני פרויקטים, חי ובדיקה, ולכל אחד מפתחות, יעדים ויומן אירועים משלו. חשבונות חדשים נוחתים בפרויקט הבדיקה, כך שהדבר הראשון שאתם מנסים הוא לא תעבורת פרודקשן.
ההפרדה הזו היא יותר מנוחות. כיוון שלכל פרויקט מפתחות משלו, ניסוי שנעשה עם המפתחות של פרויקט הבדיקה נשאר בפרויקט הבדיקה, עם היעדים ויומן האירועים שלו, ולא מתערבב עם מה שהלקוחות שלכם מקבלים. וההיתר ל-HTTP רגיל בפרויקט הבדיקה מאפשר להצביע על שרת שעוד אין לו תעודה, בזמן שהפרויקט החי ממשיך לדרוש HTTPS.
שולחים אירוע בדיקה ליעד אחד
curl -X POST https://api.hookget.com/v1/endpoints/ep_…/test \
-H "authorization: Bearer $HOOKGET_KEY"הבקשה מפרסמת אירוע hookget.test שממוען ליעד הזה בלבד. זה שימושי כשרוצים להוכיח שצרכן אחד
עובד בלי לפזר את האירוע לכל השאר. במערכת עם כמה יעדים, פרסום רגיל של אירוע בדיקה היה מגיע לכל מי שנרשם
לסוג האירוע, וכאן רק היעד שבחרתם מקבל אותו.
בודקים את מסלולי הכשל
הבדיקות המעניינות הן אלה שבהן משהו משתבש. צרכן שעובד כשהכל תקין לא מלמד הרבה, כי בפרודקשן הוא יפגוש פריסות, תקלות רשת ושרתים איטיים. הפנו יעד בדיקה לשירות שבשליטתכם, וגרמו לו לענות רע בכוונה:
| מה הוא עונה | מה אמורים לראות |
|---|---|
| 500 | ניסיון חוזר מתוזמן, והמרווח גדל בכל ניסיון |
| תגובה איטית שחורגת מה-timeout | timeout שנרשם ככשל, ולא תקיעה |
| 410 | היעד מושבת מיד |
| שום תשובה (החיבור נדחה) | שגיאת חיבור שנרשמת עם הסוג שלה |
| 200 אחרי כמה כשלים | מונה הכשלים מתאפס, וציר הזמן מראה את כל הסיפור |
כל שורה בטבלה בודקת הנחה אחרת. ה-500 מראה שהניסיונות החוזרים מתרווחים ולא מציפים את היעד. התגובה האיטית מוודאת שה-handler שלכם מאשר מהר ועושה את העבודה אחר כך. ה-410 מראה שיש דרך מפורשת לומר "תפסיקו לשלוח". וה-200 בסוף מראה שיעד שהתאושש חוזר לעבודה רגילה, עם היסטוריה מלאה של מה שקרה בדרך.
צריך לבדוק צרכנים גם מול חתימה שגויה. פונקציית אימות שאף פעם לא החזירה false בבדיקות היא פונקציית אימות שאף אחד לא הוכיח שהיא עובדת.
פרטי החתימה והפונקציה המלאה נמצאים במדריך אימות החתימות.
שאלות
איך בודקים וובהוקים בלי לפגוע בתעבורה החיה?
משתמשים בפרויקט הבדיקה. לכל חשבון יש פרויקט חי ופרויקט בדיקה, כל אחד עם מפתחות, יעדים ויומן אירועים משלו, וחשבונות חדשים נוחתים בפרויקט הבדיקה.
איך שולחים אירוע בדיקה ליעד אחד בלבד?
שולחים POST ל-/v1/endpoints/{id}/test. זה מפרסם אירוע hookget.test שממוען
רק ליעד הזה, בלי לפזר אותו לשאר היעדים שנרשמו.
אפשר להצביע על כתובת HTTP ולא HTTPS?
בפרויקט בדיקה כן. בפרויקט חי היעד חייב להיות HTTPS.
אילו תרחישי כשל כדאי לבדוק?
500, כדי לראות ניסיון חוזר עם מרווח שגדל. תגובה איטית, כדי לראות timeout שנרשם ככשל. 410, שמשבית את היעד מיד. חיבור שנדחה, שנרשם כשגיאת חיבור. ו-200 אחרי כמה כשלים, שמאפס את מונה הכשלים.
למה לבדוק מול חתימה שגויה?
כי פונקציית אימות שאף פעם לא החזירה false בבדיקות לא הוכחה. בדיקה אחת עם חתימה שגויה מראה שהצרכן באמת דוחה בקשות מזויפות, ולא רק מקבל כל מה שמגיע.
להתחיל למסור וובהוקים היום
מפנים את הוובהוקים ל-HookGet ורואים את המסירה הראשונה מגיעה, חתומה, תוך פחות מדקה.
פתיחת חשבון חינם לנסות את בודק הוובהוקים החינמי
10,000 מסירות בחודש בחינם, בלי כרטיס אשראי. המסלול החינמי חוסם ולא מחייב, כך שניסיון לא יכול להסתיים בחשבונית.