למה Requests ו-BeautifulSoup הם בזבוז זמן כאן
בואו נניח את זה על השולחן מיד: אם הגישה הראשונית שלכם ל-scraping אל על היא ספריית requests, אתם בדרך לכאב ראש. האתר הוא SPA טיפוסי, ככל הנראה מבוסס React או Angular, שבו התוכן שאתם רואים בדפדפן לא קיים במקור ה-HTML הראשוני. מה שאתם מקבלים בבקשת GET פשוטה הוא מעטפת JavaScript, לא את רשימת הטיסות או המחירים. התוכן האמיתי נטען דינמית דרך סדרה של קריאות API פנימיות לאחר שהדף הראשוני נטען.
זו הסיבה שצריך לחשוב אחרת. הפתרון הוא לא לנסות לפרסר HTML שלא קיים, אלא להשתמש בכלים שמסוגלים לרנדר JavaScript. כאן Playwright נכנס לתמונה ומנצח את Selenium בכל פרמטר רלוונטי ב-2025. הוא מהיר יותר, האמינות שלו גבוהה יותר, וה-API שלו לאינטראקציה עם הרשת פשוט מעולה. בעזרת Playwright, אנחנו יכולים לא רק לרנדר את הדף כמו דפדפן אמיתי, אלא גם ליירט את אותן קריאות API פנימיות, שהן מכרה הזהב האמיתי. ניסיון לבצע רינדור מלא לכל דף חיפוש יהיה איטי ויקר במשאבים. הגישה החכמה היא להשתמש ב-Playwright פעם אחת כדי להבין את הלוגיקה, ואז לעבור לדבר ישירות עם ה-API.
מיפוי ה-API הפנימי: איפה נמצא הזהב האמיתי
אחרי שהבנו שרינדור מלא הוא לא הדרך היעילה, המשימה הבאה היא לפצח את ה-API. פתחו את ה-DevTools של Chrome, עברו ללשונית Network, ובצעו חיפוש טיסות באתר אל על. אתם תראו מטר של בקשות. רובן לא רלוונטיות (תמונות, קבצי CSS, סקריפטים של צד שלישי), אבל ביניהן מסתתרות כמה קריאות XHR/Fetch שהן המטרה שלנו. חפשו בקשות שמחזירות JSON עם נתונים שנראים כמו פרטי טיסה, תאריכים, ומספרי טיסות.
כאן מתחיל איסוף קטלוג אל על האמיתי. ברגע שזיהיתם את ה-endpoint המרכזי לחיפוש, אתם יכולים להתחיל לשחק עם הפרמטרים שלו. תגלו שאפשר לשנות קוד של שדה תעופה, תאריך, ומספר נוסעים כדי לקבל נתונים מדויקים בלי צורך בממשק המשתמש. זה המפתח לניטור מחירים יעיל. במקום לטעון דף שלם, אתם שולחים בקשת POST או GET ממוקדת ומקבלים JSON נקי. ב-JSON הזה תמצאו שדות קריטיים כמו מחירים וזמינות לכל טיסה. זה מאפשר לבנות מערכת ניטור מחירים אל על שמסוגלת לבדוק מאות יעדים בדקה, משימה בלתי אפשרית עם רינדור דפדפן מלא. המפתח הוא להבין את ה-schema של ה-API ולחקות את הבקשות בצורה מושלמת, כולל כל ה-headers הנדרשים.
תרחיש הכישלון הקלאסי: נפילה על ניהול Session
אז מצאתם את ה-API, אתם שולחים בקשות ומקבלים נתונים. הכל נראה טוב. ואז, אחרי 200 בקשות, אתם מתחילים לקבל שגיאות או, גרוע מכך, תוצאות לא עקביות. ברוכים הבאים לסיוט של ניהול state באתרי תעופה. חיפוש טיסה באל על אינו פעולה בודדת וחסרת מצב. המערכת יוצרת עבורכם session, עוקבת אחרי החיפושים שלכם, ולפעמים מתאימה את התוצאות בהתבסס על היסטוריית החיפוש באותו session.
הטעות הנפוצה ביותר היא להתייחס לכל קריאת API כעצמאית. מהנדסים רבים שוכחים להעביר את ה-cookies הנכונים או את טוקן ה-session שקיבלו מהבקשה הראשונה. בלי זה, השרת עלול לראות כל בקשה כמשתמש חדש, מה שיכול להוביל לתוצאות שגויות או להפעלת מנגנוני הגנה. ראיתי מערכות שבהן אחוז ההצלחה צנח מ-95% לפחות מ-40% רק בגלל ניהול session לקוי. זה קריטי במיוחד במעקב מלאי/זמינות אל על, שם אתם צריכים להיות בטוחים שהמושב שאתם רואים כפנוי הוא אכן כזה. הפתרון דורש ניהול קפדני של cookies ו-headers כמו Authorization או X-CSRF-Token בין בקשות. השתמשו בספרייה כמו requests.Session אם אתם עובדים ישירות מול ה-API, או ודאו ש-Playwright מנהל את ה-context שלו נכון בין טעינות עמודים.
מתי הגישה הזו לא מספיקה: CAPTCHA ו-Fingerprinting
גם עם הגישה המתוחכמת ביותר מול ה-API, בשלב מסוים תתקלו בקיר. אתרי תעופה כמו אל על משקיעים מאמצים רבים במניעת scraping. אם תתחילו לשלוח כמות גדולה של בקשות מ-IP בודד, גם אם הן מושלמות מבחינת מבנה, אתם תזוהו. כאן נכנסים לתמונה מנגנוני הגנה מתקדמים יותר כמו CAPTCHA ו-Device Fingerprinting. רוב הסיכויים שתתקלו בפתרונות כמו Cloudflare או Akamai.
בנקודה הזו, שליחת בקשות פשוטות מפסיקה לעבוד. גם Playwright במצב רגיל עלול להיכשל. זה הזמן לשדרג את המערך. ראשית, חובה להשתמש ב-proxy rotation עם proxies מסוג residential. פרוקסי מ-datacenter יזוהה וייחסם תוך דקות. שנית, צריך להשתמש בגרסאות 'stealth' של כלי אוטומציה, למשל דרך שימוש ב-מדריך Playwright stealth כדי להסוות את העובדה שאתם מריצים דפדפן אוטומטי. המטרה היא להיראות כמו משתמש אנושי אמיתי, עם טביעת אצבע ייחודית של דפדפן ו-IP שנראה כמו משתמש ביתי. חשוב גם לנהל את קצב הבקשות. היצמדות לקצב של מתחת ל-20 בקשות בדקה לאותו IP יכולה לעשות את ההבדל בין הצלחה לחסימה. אם נתקלתם בקיר של Cloudflare, יש טכניקות ייעודיות להתמודדות איתו, אבל זה כבר נושא למאמר אחר.
מנתונים גולמיים לתובנות עסקיות: מודיעין ו-API
בסופו של דבר, המטרה של scraping אל על היא לא רק לאסוף נתונים, אלא להפוך אותם למוצר בעל ערך. כאן נכנסים שני מקרי שימוש מרכזיים. הראשון הוא מודיעין מתחרים אל על. חברות תיירות ומתחרים יכולים לעקוב אחרי שינויי מחירים, הוספת קווים חדשים, או שינויים בזמינות המושבים כדי לקבל החלטות אסטרטגיות. לדוגמה, זיהוי אוטומטי של מבצע חדש על קו תל אביב-ניו יורק מאפשר למתחרה להגיב במהירות עם מבצע משלו. המערכת צריכה לא רק לאסוף את הנתונים, אלא גם לנרמל אותם, לזהות שינויים, ולהפיק התראות.
המקרה השני הוא יצירת API / קובץ נתונים אל על לשימוש פנימי או חיצוני. במקום שכל צוות בחברה ימציא את הגלגל מחדש, בונים scraper מרכזי, אמין ויציב. ה-scraper הזה מזין את הנתונים למסד נתונים, ומשם חושפים אותם דרך API פנימי. כך, צוותי אנליטיקה, שיווק ומוצר יכולים לצרוך נתוני טיסות עדכניים בלי להתעסק במורכבות של ה-scraping עצמו. אפשר להפיק ייצוא CSV יומי של כלל הטיסות והמחירים, או לספק endpoint של API שמחזיר מחיר לטיסה ספציפית לפי דרישה. בניית תשתית כזו דורשת חשיבה על טיפול בשגיאות 429 וניטור קבוע, אבל הערך שהיא מספקת לארגון הוא עצום.