Webhooks מוסברים¶
מתי שירות תשלומים חיצוני מודיע לכם שתשלום הצליח, איך המערכת שלכם יודעת את זה? אפשר לשאול שוב ושוב "האם התשלום הצליח כבר?" כל כמה שניות, אבל זה מבזבז משאבים ולא באמת מיידי. הפתרון הנפוץ הרבה יותר הוא webhook - השירות החיצוני פשוט מודיע לכם ביוזמתו, ברגע שמשהו קורה.
אז מה זה בעצם Webhook¶
webhook הוא בעצם API הפוך. ב-API רגיל, אתם הצד שיוזם את הבקשה - אתם שולחים בקשה לשרת, והוא עונה. ב-webhook, התפקידים מתהפכים - אתם נותנים לשירות החיצוני כתובת URL אצלכם, ומבקשים ממנו "כשיקרה אצלך אירוע מסוים, שלח בקשת HTTP לכתובת הזאת". כשהאירוע קורה בפועל, השירות החיצוני שולח בקשת POST לכתובת שנתתם, עם פרטי האירוע בגוף הבקשה.
זה בדיוק המנגנון מאחורי הרבה אינטגרציות מוכרות - שירות תשלומים שמודיע על עסקה שהושלמה, מערכת גיטהאב שמודיעה כשמישהו פתח Pull Request, שירות שליחת הודעות שמודיע שהודעה נמסרה בהצלחה.
למה זה עדיף על שאילת מצב (polling)¶
הגישה החלופית, polling, אומרת שהמערכת שלכם שואלת שוב ושוב "יש חדש?" בפרקי זמן קבועים. הבעיה היא שזה גם מבזבז משאבים על שאלות שרוב הזמן התשובה להן היא "אין כלום חדש", וגם לא מיידי - אם שאלתם לפני שנייה ואירוע קרה שנייה אחרי זה, תגלו רק בשאילתה הבאה. webhook פותר את שתי הבעיות - אין שאלות מיותרות, וההודעה מגיעה ברגע שהאירוע קורה, לא מאוחר יותר.
איך בונים נקודת קצה שמקבלת webhook¶
מהצד המקבל, webhook הוא פשוט endpoint רגיל שמאזין לבקשות POST. אבל יש כמה דברים שחשוב לזכור. ראשית, צריך לענות מהר - השירות השולח מצפה לתשובה תוך זמן קצר, ואם ה-endpoint שלכם עסוק בעיבוד כבד לפני שהוא עונה, השירות השולח עלול לחשוב שהבקשה נכשלה ולנסות לשלוח אותה שוב. הפתרון המקובל הוא לאשר קבלה מיד עם קוד סטטוס 200, ולהעביר את העיבוד הכבד לתור עבודה ברקע.
שנית, ה-endpoint צריך להיות אידמפוטנטי - כלומר, לדעת להתמודד עם קבלה כפולה של אותו אירוע בלי לגרום לבעיה, כי כמעט כל שירות שולח webhook פעם נוספת אם הוא לא קיבל אישור בזמן, וזה יכול לקרות גם כשהעיבוד הראשוני בכל זאת הצליח.
אבטחה - למה אסור לסמוך על כל בקשה שמגיעה¶
נקודת קצה שמקבלת webhook היא כתובת ציבורית שמקבלת בקשות POST - ובלי הגנה, כל אחד יכול לשלוח לה בקשה מזויפת שמתחזה לאירוע אמיתי. שירותים רציניים פותרים את זה עם חתימה דיגיטלית - הם חותמים כל בקשה עם מפתח סודי משותף, ומצרפים את החתימה ל-header. הקוד שלכם, לפני שהוא מטפל בבקשה, מחשב את החתימה בעצמו ומשווה אותה למה שהתקבל. אם הן לא תואמות, הבקשה נדחית מיד. דילוג על הבדיקה הזאת הוא טעות אבטחה נפוצה שמאפשרת לכל אחד להזרים אירועים מזויפים למערכת שלכם.
מה קורה כשהבקשה נכשלת¶
רשתות לא אמינות ב-100 אחוז, ולפעמים בקשת webhook פשוט לא מגיעה, או מגיעה אבל השרת שלכם היה זמנית לא זמין. שירותים טובים מיישמים לוגיקת retry - אם לא קיבלו אישור, הם מנסים לשלוח שוב, לרוב עם השהיה גדלה בין ניסיון לניסיון. זו עוד סיבה טובה מדוע חשוב שה-endpoint שלכם יהיה אידמפוטנטי, כדי שניסיון חוזר לא יגרום לעיבוד כפול של אותו אירוע.
איך לומדים לבנות ולצרוך webhooks נכון¶
בניית endpoint שמקבל webhooks באמינות ובבטחה, כולל אימות חתימה וטיפול בכפילויות, זה משהו שנלמד הכי טוב תוך כדי שילוב אמיתי עם שירות חיצוני. בקורס צד-שרת בונים אינטגרציות אמיתיות שכוללות webhooks, בדיוק כמו שזה נראה בפרויקטים אמיתיים.
משלבים שירות חיצוני שמשתמש ב-webhooks ונתקלים בבעיה? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.
לסיכום¶
Webhook הופך את כיוון התקשורת הרגיל - במקום לשאול שוב ושוב אם קרה משהו, השירות החיצוני מודיע לכם ביוזמתו ברגע שקרה. זה יעיל ומיידי, אבל דורש בניית endpoint שעונה מהר, מטפל בכפילויות בלי להישבר, ומאמת שכל בקשה שמגיעה אכן באה מהמקור האמיתי ולא מתחזה.