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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

[clear]
איך השרת אומר לנו אם הבקשה הצליחה או נכשלה? באמצעות HTTP Status Codes. אלו מספרים בני שלוש ספרות. משפחת 2xx, כמו 200 OK או 201 Created, מסמנת הצלחה. משפחת 4xx מסמנת בעיה בצד הלקוח. למשל, 400 Bad Request אומר ששלחנו משהו לא תקין, 401 Unauthorized אומר שאין לנו הרשאה, ו-404 Not Found אומר שהמשאב לא קיים. משפחת 5xx מסמנת בעיה בצד השרת. הבנת הקודים האלה חוסכת שעות של דיבאגינג. למשל, אם נשלח בקשה עם מפתח API לא נכון, אנחנו צפויים לקבל 401.

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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

[מעבר שקף]

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