מדריכי וובהוקים
הבעיות שצצות ברגע שוובהוקים עולים לפרודקשן, ולכל אחת ההסבר והקוד.
המסירה הראשונה שלכם
חשבון, יעד, פרסום של אירוע, וציר הזמן שמוכיח שהוא הגיע.
אימות חתימות של וובהוקים
שלוש הכותרות, פונקציית אימות, והטעות שכולם עושים פעם אחת.
ניסיונות חוזרים ומניעת כפילויות
מה נשמר בניסיון חוזר, ואיך צרכן נמנע מלטפל באותו אירוע פעמיים.
תור הכשלים והחזרה לפעולה
מה קורה כשלוח הניסיונות נגמר, ואיך מחזירים את האירועים.
עיבוד מקדים של תוכן האירוע לכל יעד
שש פעולות הצהרתיות שמעצבות מסירה מחדש לפני החתימה, ולמה אנחנו אף פעם לא מריצים את ה-JavaScript שלכם.
מסירת וובהוקים לתור במקום לכתובת URL
SQS, SNS, EventBridge, Pub/Sub, Service Bus, Kafka, RabbitMQ, דליים תואמי S3 ויעד משיכה, לצרכן שלא יפתח פורט נכנס.
פיתוח מקומי מול אירועים אמיתיים
קובץ אחד, בלי מנהרה: העברת אירועים חתומים אמיתיים ל-localhost, כדי שהקוד שלכם ייבדק מול אירועים אמיתיים.
בדיקת וובהוקים
איך מפעילים צרכן בלי לחכות לתעבורה אמיתית.
איתור תקלה במסירה שנכשלת
קריאת ציר הזמן: מה כל קוד סטטוס אומר בדרך כלל, ומה עושים איתו.
וובהוקים ו-SSRF
למה שירות מסירה הוא מכונת SSRF מעצם הגדרתו, ואיך תוחמים אותו.
איזה מדריך עונה על השאלה שלכם
| אם אתם שואלים | קראו את |
|---|---|
| “איך מוכיחים שוובהוק באמת הגיע מכם?” | אימות חתימות |
| “למה הצרכן שלי קיבל את אותו אירוע פעמיים?” | ניסיונות חוזרים ומניעת כפילויות |
| “לאן הולכים אירועים כשיעד לא זמין?” | תור הכשלים והחזרה לפעולה |
| “למה המסירה הזו נכשלת?” | איתור תקלה במסירה |
| “איך בודקים את זה בלי תעבורה אמיתית?” | בדיקת וובהוקים |
| “האם כתובת של לקוח יכולה להגיע לרשת הפנימית שלי?” | וובהוקים ו-SSRF |
| “איך מביאים את המסירה הראשונה לעבוד?” | המסירה הראשונה שלכם |
| “הלקוח שלי רוצה את האירועים בתור שלו, לא בכתובת URL” | מסירה לתור |
| “כל יעד צריך את תוכן האירוע במבנה אחר” | עיבוד מקדים לכל יעד |
| “איך מקבלים אירועים אמיתיים על המחשב שלי?” | פיתוח מקומי |
למה דווקא המדריכים האלה
לשלוח בקשת POST זה קל, וכמעט כל צוות כותב את הגרסה הראשונה של מערכת הוובהוקים שלו בערב אחד. העמודים האלה נכתבו בשביל מה שבא אחר כך: יעד שנפל באמצע פריסה, צרכן שקיבל אותו אירוע פעמיים ושלח שתי חשבוניות, framework שפענח את גוף הבקשה לפני שהקוד שלכם הספיק לאמת את החתימה, ולקוח שכותב לתמיכה "לא קיבלנו כלום" כשאין לכם איך לבדוק. כל מדריך כאן מתחיל מבעיה אחת כזו, מסביר למה היא קורית, ונותן את הקוד או את הקריאה ל-API שפותרים אותה.
ארבעת המדריכים הראשונים הם הבסיס: איך שולחים ורואים מסירה, איך מאמתים אותה, מה קורה כשהיא נכשלת, ולאן היא הולכת כשכל הניסיונות נגמרו. שאר המדריכים עוסקים במצבים שמגיעים בהמשך, כמו לקוח שרוצה את האירועים בתור משלו, יעד שצריך מבנה אחר של תוכן האירוע, או השאלה אם כתובת שלקוח הזין יכולה להפוך לדלת אל הרשת הפנימית שלכם. אם אתם עוד מנסים להבין את התמונה הכללית, ההסבר על וובהוקים יסדר לכם את המונחים לפני שנכנסים לפרטים.
שאלות
באיזה סדר כדאי לקרוא את המדריכים?
אם עוד לא שלחתם אף אירוע, התחילו במסירה הראשונה: היא לוקחת כמה דקות ומראה את כל הצינור מקצה לקצה. מיד אחריה אימות חתימות, כי זה הקוד הראשון שכותבים בצד המקבל. את הניסיונות החוזרים ואת תור הכשלים כדאי לקרוא לפני שעולים לתעבורה חיה, לא אחרי התקלה הראשונה.
המדריכים רלוונטיים רק למי שמשתמש ב-HookGet?
לא. הבעיות עצמן קיימות בכל מערכת וובהוקים: חתימה על הגוף המקורי, מזהה מסירה קבוע, לוח ניסיונות חוזרים, ומה עושים עם מסירה שלא הגיעה. HookGet חותם לפי Standard Webhooks, שהוא מפרט פתוח, ולכן גם קוד האימות מתאים לכל שולח שעומד בו. הדוגמאות משתמשות ב-API שלנו, אבל ההיגיון מאחוריהן כללי.
מה ההבדל בין ניסיון חוזר לשליחה חוזרת?
ניסיון חוזר הוא אוטומטי: מסירה נכשלה, והמערכת מנסה שוב לפי לוח זמנים קבוע. שליחה חוזרת היא
פעולה מכוונת: אתם בוחרים אירוע שכבר נשמר, בדרך כלל מתור הכשלים, ושולחים אותו שוב אחרי שהיעד תוקן.
בשני המקרים מזהה המסירה נשאר זהה, ולכן צרכן שמונע כפילויות לפי webhook-id מוגן בשניהם.
איך בודקים צרכן בלי תעבורה אמיתית?
מדריך הבדיקות מסביר איך שולחים אירוע בדיקה ליעד אחד ואיך מפעילים בכוונה את מסלולי הכשל. אם אתם מפתחים על המחשב שלכם, המדריך לפיתוח מקומי מראה איך מקבלים אירועים חתומים אמיתיים ב-localhost בלי מנהרה.
להתחיל למסור וובהוקים היום
מפנים את הוובהוקים ל-HookGet ורואים את המסירה הראשונה מגיעה, חתומה, תוך פחות מדקה.
פתיחת חשבון חינם לנסות את בודק הוובהוקים החינמי
10,000 מסירות בחודש בחינם, בלי כרטיס אשראי. המסלול החינמי חוסם ולא מחייב, כך שניסיון לא יכול להסתיים בחשבונית.