[warm]
שלום לכולם וברוכים הבאים לשיעור חמש נקודה אחת בקורס AI Engineer. היום נצלול לעולם ה-API, HTTP, REST, וכל מה שביניהם.

[calm]
במודול הקודם, ובמיוחד בשיעור ארבע נקודה שש, למדנו להשתמש בכלי בינה מלאכותית כדי ליצור נכסים שיווקיים מדהימים, כמו סרטונים. השתמשנו בממשקים גרפיים, לחצנו על כפתורים וקיבלנו תוצאה. אבל מה קורה מאחורי הקלעים? איך האפליקציה שלכם, כשתבנו אותה, תבקש מ-Claude לכתוב תסריט או מ-Gemini לנתח דאטה? התשובה היא API, ראשי תיבות של Application Programming Interface. היום אנחנו עוברים מכיסא הנהג לחדר המנועים. הבנת API היא לא מיומנות טכנית צדדית, היא הליבה של בניית כל מוצר AI מודרני. שאלה שכדאי לחשוב עליה היא, האם שמעתם פעם את המונח API בהקשר עסקי, לאו דווקא טכני? ואיפה זה צץ?

[מעבר שקף]

[calm, confident]
בבסיסו, API הוא חוזה. הוא מגדיר את הדרכים שבהן תוכנה אחת יכולה לבקש שירותים מתוכנה אחרת. האנלוגיה הטובה ביותר היא מסעדה. אתם הלקוחות, כלומר האפליקציה שלכם, המטבח הוא המערכת שמבצעת את העבודה, למשל המודל של OpenAI, וה-API הוא המלצר. אתם מקבלים תפריט, שזה בעצם התיעוד של ה-API, עם רשימה ברורה של מה שאפשר להזמין. אתם אומרים למלצר בדיוק מה אתם רוצים, וזו בקשת ה-API שלכם. המלצר לוקח את ההזמנה למטבח, וכשהמנה מוכנה, הוא מביא אותה לשולחן. זו תגובת ה-API. חשבו רגע, לפי האנלוגיה הזו, מה יכול להשתבש בתקשורת מול המלצר, ואיך זה יתבטא בעולם ה-API?

[מעבר שקף]

[calm]
אז למה זה כל כך חשוב לעסקים? API הוא מנוע צמיחה. הוא מאפשר לחברות להתמקד בערך הליבה שלהן ולהשתמש בשירותים חיצוניים לכל השאר. דמיינו את Wix: הם לא בנו מערכת סליקה מאפס. הם התחברו באמצעות API לחברות כמו Stripe או PayPal. חברות פינטק ישראליות כמו Rapyd או Payoneer בנו את כל העסק שלהן על API. ה-API מאפשר חדשנות מהירה, יצירת אקוסיסטם שלם סביב מוצר, וייעול תהליכים. אפילו הממשלה מבינה את הכוח הזה, ודרך פורטל api.gov.il, מפתחים יכולים לקבל גישה לנתונים ציבוריים. בעולם ה-AI, ה-API הוא המוצר. נקודה למחשבה: איזה עוד שירות שאתם מכירים כנראה משתמש ב-API של חברה אחרת כדי לתפקד?

[מעבר שקף]

[calm, confident]
חשוב להבין שלא כל API זהה. אנחנו נתמקד בקורס ב-Web APIs, שהם הנפוצים ביותר, אבל כדאי להכיר את התמונה הרחבה. ישנם שלושה סוגים עיקריים. הראשון הוא Library APIs, כשאנחנו משתמשים בספרייה כמו `requests` או `pandas` בפייתון. השני הוא OS APIs, שמערכת ההפעלה חושפת כדי לתקשר עם החומרה. והשלישי הוא Web APIs, שבהם נתמקד. הם מאפשרים תקשורת בין מערכות שונות דרך האינטרנט, בדרך כלל באמצעות פרוטוקול HTTP. ה-API של גוגל, OpenAI, ופייסבוק כולם Web APIs. וכשאנחנו נתחבר ל-Claude כדי לבקש ממנו לכתוב טקסט, שאלה טובה היא לאיזו קטגוריה זה ישתייך, ולמה.

[מעבר שקף]

[calm, confident]
כדי שמערכות יבינו אחת את השנייה דרך הרשת, הן צריכות לדבר באותה שפה. השפה הזו היא HTTP, ראשי תיבות של HyperText Transfer Protocol. זהו הבסיס של כל האינטרנט. כל פעם שאתם גולשים לאתר, הדפדפן שולח בקשת HTTP לשרת, והשרת עונה עם תגובת HTTP. חשוב להבין ש-HTTP הוא פרוטוקול של בקשה-תגובה. הלקוח תמיד יוזם את השיחה. זהו גם פרוטוקול Stateless, כלומר 'חסר מצב'. השרת לא זוכר את הבקשה הקודמת שלכם, אלא אם כן אנחנו מוסיפים מידע שיעזור לו. שאלה מעניינת היא, איך 'חוסר המצב' של HTTP יכול להיות יתרון, ואיך הוא יכול להיות חיסרון?

[מעבר שקף]

[calm, confident]
לבקשת HTTP יש כוונה, פועַל. הפעלים האלה נקראים HTTP Methods. יש כמה, אבל ארבעת המרכזיים שחייבים להכיר הם: GET, המשמש לקבלת מידע מהשרת, כמו לשאול איפה נמצא ספר. POST, המשמש ליצירת משאב חדש, כמו להגיש כתב יד חדש לספרייה. PUT או PATCH, המשמשות לעדכון משאב קיים. ו-DELETE, המשמשת למחיקת משאב מהשרת. השימוש הנכון במתודות האלה הוא קריטי כדי ליצור API נקי וברור. שאלה טובה לחשוב עליה היא, אם אני רוצה לעשות 'לייק' לפוסט בפייסבוק דרך API, באיזו מתודה לדעתכם הכי נכון להשתמש?

[מעבר שקף]

[calm]
תיאוריה זה נחמד, אבל בואו נראה את זה בפעולה. אני אשתמש בכלי שנקרא Postman כדי לשלוח בקשות HTTP אמיתיות ל-API ציבורי בשם JSONPlaceholder. ראשית, נבצע בקשת GET כדי לקבל רשימה של 'פוסטים'. תראו את כתובת ה-URL, את בחירת המתודה, ואת התגובה שנקבל בפורמט JSON. לאחר מכן, נבצע בקשת POST כדי 'ליצור' פוסט חדש. תראו איך אנחנו מוסיפים Body לבקשה, שמכיל את המידע שאנחנו רוצים לשלוח לשרת. נראה גם איך השרת מגיב עם המשאב החדש שנוצר, בדרך כלל עם מזהה ייחודי. ננתח יחד את מבנה הבקשה והתגובה.

[מעבר שקף]

[clear]
איך השרת אומר לנו אם הבקשה הצליחה, נכשלה, או שהוא בכלל לא הבין מה רצינו? באמצעות HTTP Status Codes. אלו מספרים בני שלוש ספרות שמתחילים כל תגובת HTTP. הם מחולקים למשפחות, ובאנלוגיה פשוטה אפשר לחשוב עליהם כמו רמזור. קודי מאתיים, כמו מאתיים OK ומאתיים ואחת Created, הם אור ירוק. הבקשה הצליחה. קודי ארבע מאות, כמו ארבע מאות וארבע Not Found, הם אור צהוב. אתם, הלקוחות, עשיתם משהו לא בסדר. וקודי חמש מאות הם אור אדום. הבעיה בשרת. הבנת הקודים האלה חוסכת שעות של דיבאגינג. שאלה טובה היא, אם אשלח בקשת GET ל-API של OpenAI עם מפתח API לא נכון, איזה קוד סטטוס אני צפוי לקבל?

[מעבר שקף]

[calm, confident]
בטח שמעתם את המונח REST API. חשוב להבין ש-REST, או Representational State Transfer, הוא לא פרוטוקול או תקן, אלא סגנון אדריכלי. זוהי מערכת של עקרונות וכללים לבניית Web APIs. רוב ה-APIs המודרניים הם RESTful, או לפחות שואפים להיות. הרעיון המרכזי ב-REST הוא שהכל הוא 'משאב'. משתמש הוא משאב, פוסט הוא משאב, תמונה היא משאב. כל משאב מזוהה על ידי URL ייחודי, ואנחנו משתמשים בפעלי ה-HTTP כדי לבצע פעולות על המשאבים האלה. זה יוצר API שהוא מאוד אינטואיטיבי וקל להבנה.

[מעבר שקף]

[calm, confident]
כדי ש-API ייחשב RESTful, הוא צריך לעמוד בכמה עקרונות, כשהחשובים הם הפרדה בין לקוח לשרת, היותו Stateless, וקיום ממשק אחיד. ממשק אחיד הוא הליבה. זה כולל זיהוי משאבים באמצעות URL, שנקראים Endpoints, שימוש במתודות HTTP סטנדרטיות, והחזרת מידע בפורמט מוסכם, בדרך כלל JSON. אפשר לחשוב על זה כמו מכונת שתייה: יש לה כתובת ברורה, לכל מוצר יש קוד ייחודי, ואתם משתמשים בכפתורים סטנדרטיים כדי לקבל את המוצר. המכונה לא זוכרת מה קניתם קודם. בהמשך לדוגמת הספרייה, איך תיראה בקשת DELETE למחיקת ספר עם ID מספר ארבעים ושתיים?

[מעבר שקף]

[calm]
אם בקשת ה-API היא מכתב, ה-URL הוא הכתובת וה-Body הוא התוכן, אז ה-Headers הם מה שכתוב על המעטפה: מי השולח ובאיזו שפה המכתב כתוב. Headers הם פיסות מטא-דאטה שנשלחות עם כל בקשה ותגובה. ישנם Headers סטנדרטיים רבים. למשל, Content-Type מציין את הפורמט של ה-Body, ו-Accept מציין את הפורמטים שהלקוח מוכן לקבל. Header חשוב נוסף הוא Authorization, שמכיל את פרטי האימות שלנו, ועליו נרחיב מיד. כדאי לחשוב, כשאנחנו שולחים בקשת POST עם גוף JSON, איזה Header חיוני שנוסיף כדי שהשרת יבין אותנו?

[מעבר שקף]

[calm]
רוב ה-APIs המעניינים בעולם לא פתוחים לכולם. הם דורשים אימות, כלומר Authentication. יש לכך כמה סיבות. הראשונה היא אבטחה, כדי לוודא שרק משתמשים מורשים ניגשים למידע. השנייה היא מעקב וניטור, כדי להגביל את מספר הקריאות ולמנוע הצפה. השלישית היא חיוב, כדי לדעת את מי לחייב על השימוש. ה-API של OpenAI עולה כסף, והם חייבים לדעת מי אתם. והרביעית היא פרסונליזציה, כדי לספק תגובות מותאמות אישית. בלי אימות, האינטרנט היה פרוץ והרבה מודלים עסקיים לא היו יכולים להתקיים.

[מעבר שקף]

[clear]
חשוב מאוד להבדיל בין שני מונחים: Authentication, כלומר אימות, ו-Authorization, כלומר הרשאה. Authentication זה תהליך הוכחת הזהות. זה לענות על השאלה 'מי אתה?'. באנלוגיה, זה כמו להראות תעודת זהות בכניסה לבניין. השומר מאמת שאתה אכן עובד בחברה. Authorization זה תהליך קביעת ההרשאות. זה לענות על השאלה 'מה מותר לך לעשות?'. אחרי שנכנסת לבניין, כרטיס העובד שלך מאפשר לך לפתוח דלתות מסוימות, אבל לא אחרות. קודם כל מבצעים אימות, ורק אחר כך בודקים הרשאות.

[מעבר שקף]

[calm, confident]
השיטה הפשוטה והנפוצה ביותר לאימות ב-APIs היא API Key. זהו רצף תווים ארוך וייחודי שהשרת מנפיק לכם, ואתם צריכים לכלול אותו בכל בקשה. זה כמו מפתח לספריה פרטית. כל עוד אתם מציגים אותו בכניסה, יודעים שאתם חברים. רוב ה-AI APIs, כמו OpenAI ו-Claude, משתמשים בשיטה זו. בדרך כלל שולחים את המפתח ב-Header של Authorization. היתרון הוא פשטות. החיסרון הוא שאם המפתח דולף, מישהו יכול להשתמש בו ולהתחזות לכם. שאלה חשובה היא, איפה המקום הכי גרוע לשמור API Key בפרויקט תוכנה?

[מעבר שקף]

[calm]
בואו נראה איך זה עובד בפועל. נשתמש בספריית `requests` בפייתון כדי לשלוח בקשה ל-API שדורש מפתח, למשל API חינמי למזג אוויר. ראשית, ננסה לשלוח בקשה בלי המפתח, ונראה שנקבל שגיאת ארבע מאות ואחת Unauthorized. לאחר מכן, נוסיף את המפתח שלנו ל-Header של הבקשה. נראה איך יוצרים אובייקט headers בפייתון, מוסיפים לו את ה-Authorization Header עם המפתח הנכון, ואז נשלח את הבקשה שוב. הפעם נראה שנקבל תשובת מאתיים OK עם נתוני מזג האוויר.

[מעבר שקף]

[calm, confident]
שלב אחד מעל API Key הוא שימוש ב-Bearer Tokens, ובמימוש נפוץ שלהם שנקרא JWT, או JSON Web Token. באנלוגיה, זה כמו צמיד לפסטיבל. אתם מציגים כרטיס בכניסה פעם אחת, ומקבלים צמיד. מרגע זה, אתם פשוט מראים את הצמיד. ה-Bearer Token עובד כך: הלקוח מזדהה פעם אחת, ומקבל בתמורה טוקן זמני. בכל בקשה עוקבת, הוא מצרף את הטוקן הזה ל-Header. JWT הוא פורמט פופולרי לטוקנים כאלה, כי הוא יכול להכיל בתוכו מידע חתום דיגיטלית, כמו מזהה המשתמש, הרשאותיו ותאריך תפוגה. מה היתרון הגדול של טוקן עם תאריך תפוגה, בהשוואה ל-API Key שלא פג תוקף?

[מעבר שקף]

[calm]
ומה קורה כשאפליקציה צד ג' רוצה לגשת למידע שלכם שנמצא בשירות אחר? למשל, כש-Canva רוצה לגשת לתמונות שלכם ב-Google Photos. אתם בוודאי לא רוצים לתת ל-Canva את הסיסמה שלכם לגוגל. כאן נכנס לתמונה OAuth שתיים נקודה אפס. זהו פרוטוקול סטנדרטי להרשאה, Authorization. הוא מאפשר למשתמש לתת לאפליקציה אחת גישה מוגבלת לנתונים שלו שנמצאים באפליקציה אחרת, מבלי לחשוף את פרטי ההזדהות. זה כמו לתת 'מפתח ואלט' לרכב – מפתח עם הרשאות מוגבלות. כך, המשתמשים שומרים על שליטה מלאה במידע שלהם.

[מעבר שקף]

[clear]
התהליך הנפוץ והמאובטח ביותר ב-OAuth שתיים נקודה אפס נקרא 'Authorization Code Flow'. הנה סקירה מהירה של הריקוד בין המשתמש, האפליקציה, והשרת של גוגל. ראשית, המשתמש לוחץ 'התחבר עם גוגל'. שנית, האפליקציה מפנה את הדפדפן לגוגל. שלישית, גוגל מבקש מהמשתמש אישור לגשת למידע ספציפי. רביעית, המשתמש מאשר. חמישית, גוגל מחזירה את הדפדפן לאפליקציה עם 'קוד הרשאה' חד-פעמי. שישית, שרת האפליקציה לוקח את הקוד ופונה ישירות לגוגל. שביעית, גוגל מאמתת את הקוד ומחזירה Access Token. מרגע זה, האפליקציה משתמשת בטוקן כדי לבצע קריאות API בשם המשתמש.

[מעבר שקף]

[calm]
בואו נראה את זה קורה מול העיניים שלנו. אני אפתח דפדפן, אכנס לאתר כמו Asana, ואבחר באפשרות 'Continue with Google'. שימו לב לכל שלב. הקליק על הכפתור מתחיל את התהליך. שימו לב ל-URL – אנחנו מופנים לכתובת של גוגל. עכשיו גוגל מציג מסך הסכמה, שמפרט בדיוק מה האפליקציה מבקשת. אלה ה-Scopes. אני מאשר. שימו לב שוב ל-URL – גוגל מפנה אותי חזרה לאתר המקורי, וב-URL יש פרמטר ארוך שנקרא `code`. זהו קוד ההרשאה. מאחורי הקלעים השרת מקבל את ה-Access Token. והנה, אני מחובר לחשבון.

[מעבר שקף]

[warm]
היום עברנו דרך ארוכה וחשובה. התחלנו מהשאלה 'מהו API' והפכנו אותה למערכת כללים מוגדרת. למדנו ש-API הוא חוזה תקשורת ומנוע צמיחה. צללנו ל-HTTP, השפה של הרשת. הגדרנו את REST כסגנון אדריכלי. ראינו איך Headers מוסיפים מטא-דאטה. ולבסוף, עסקנו באבטחה, הבחנו בין Authentication ל-Authorization, וסקרנו את השיטות המרכזיות: API Keys, Bearer Tokens, ו-OAuth שתיים נקודה אפס. בשיעור הבא, חמש נקודה שתיים, ניקח את כל התיאוריה הזאת ונהפוך אותה לקוד פייתון מעשי. נתחבר ל-API של OpenAI, Claude ו-Gemini. זה הרגע שבו הכל מתחבר. תודה רבה, ואני כאן לשאלות אחרונות.