ברוכים הבאים לפרק נוסף של פניני ידע מבית מייקרוסופט. אני המערך שלכם, מירקופיטרס. הנושא של היום הוא כזה שכמעט כולם שמרו עליו, אך מעטים באמת מבינים ממשקי תכנות יישומים, API's. כנראה שמעתם את המונח הזה נזרק להעביר לא מעט פעמים. זו אחת מאותן מילים טכנולוגיות שאנשים משתמשים בהן כשהם רוצים להישמע כאילו הם מבינים על מה הם מדברים. אבל הנה העניין, API's הם למעשה דבר פשוט. הם פשוט דרך שבה פיסת תוכנה אחת מדברת עם אחרת. הטלפון שלכם מבקש נתונים משרה. השרת שולח אותם בחזרה. זו קריאת API. עכשיו דמיינו שיש לכם 20 ממשקי API, או 50, או 100. כל אחד מהם עשוי להשתמש בעימות שונה, במגבלות קצב שונות, ובטיעות שונה אם בכלל יש כזה. פתאום, מה שהתחיל כשיחה פשוטה בין שתי אפליקציות הופך לחאוס מוחלט. ללא מנהל מרכזי, כל צוות ממציא את הגלגל מחדש. צוות אחד בונה מערכת עימות משלו, אחר בונה מערכת רישום אירועי משלו. פרצות הבטחה מופיעות בכל מקום. מפתחים מתבלבלים לגבי מה עושה כל API, ואין לכם תצוגה אחת של מה שבאמת קורה בכל המערכת שלכם.

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

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

אז מה זה בדיוק Azure API Management? הנה ההגדרה הפשוטה ביותר. זהו שירות מנוהל שיושב בין ה-API של ה-Back-End שלך לבין האפליקציות, אתרים, מכשירים ושותפים שצורכים אותם. אבל העניין הוא שזה לא רק פרוקסי. פרוקסי רק מעביר תעבורה וזהו. Azure API Management מכסה את כל מחזור החיים של ה-API שלך. פרסום, הבטחה, ניטור ובסוף גם הוצאה משימוש. זהו מרכז בקרה מלא. בואו נחלק את זה לשלושה רכיבים עיקריים. הראשון הוא הגאטאווי. זו דלת הכניסה הראשית. כל בקשה נכנסת מאפליקציה או אתר מגיעה קודם לגייטווי לעולם לא ישירות למד-Back-End שלך. הגאטאווי מאבד את הבקשה, אוכף מדיניות שהגדרת, אוסף מדדים ואז מעביר אותה לשירות ה-Back-End הנכון. תחשוב על זה כשוטר תנועה. הבא בתור הוא מישור הניהול Management Plane. כאן אתה מגדיר הכל. את ה-API, המדיניות, המוצרים והמינויים שלך. אתה עושה זאת דרך פורטל Azure,

פורטל המפתחים. זהו אתר בשירות עצמי שבו מפתחים, פנימיים וחיצוניים, יכולים לגלות את ה-API שלך, לקרות תיעוד, לקבל מפתחות מינוי ואפילו לבדוק קריאות API ישירות בדפדפן. לא עוד שליחת קבצי PDF הלוך ושוב. הנה אנלוגיה שעוזרת להבין. תחשוב על שדה תעופה מודרני. הגאטאווי הוא מסלול ההמראה. כל מטוס נוחת שם קודם. מישור הניהול הוא מגדל הפיקוח. הוא מכוון את התנועה, קובע חוקים ומנטר הכל. ופורטל המפתחים הוא לוח המידע. טייסים בודקים אותו לפני הטיסה ויכולים למצוא את כל המידע שהם צריכים בלי לדבר עם אף אחד. עכשיו, בואו נתמקד בגאטאווי. זה החלק שהאפליקציות שלך באמת מדברות איתו ושם קורה הקסם האמיתי. הגאטאווי, דלת הכניסה של ה-API שלך. בואו נדבר על הגאטאווי כי זה החלק שהאפליקציות שלך באמת מדברות איתו. כל בקשה מאפליקציה לנייד, אתר אינטרנט או מכשיר IOT מגיעה קודם כל לשער לעולם לא ישירות לשרת האחורי שלכם. זו בדיוק כל המטרה. השער יושב בחזית ומשמש כנקודת כניסה יחידה. השער יכול להכיל מדיניות לפני העברת הבקשה הלאה. מדיניות היא כללים שאתם כותבים ב-XML או JSON כמו הגבלת קצב, סינון IP, כתיבה מחדש של כותרות ובדיקות אימות.

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

התעבורה מנוטבת אוטומטית לקרוב ביותר, מה שנותן שיהוי נמוך יותר וחוויה טובה יותר. עוד דבר, השער מסתיר את כתובת ה-URL, האמיתית של השרת האחורי שלכם. לקוחות רואים רק את כתובת השער. שרתי Hey Back End שלכם נשארים חבויים מהאינטרנט. זהו יתרון הבטחה עצום שניתן כברירת מחדל. מדיניות, המנוע ששולט בכל דבר. אז מה לגבי אותן מדיניות שהזכרתי? הן המנוע שהופך את A-PIM לעוצמתי באמת. מדיניות משנה את התנהגות הבקשה או התגובה בלי שתצטרכו לגעת בקוד השרת האחורי. חישבו על זה כעל מעטפת סביב ה-API שלכם. כשהתעבורה זורמת דרכו, הוא יכול להוסיף, להסיר או לשנות דברים באופן אוטומטי. מדיניות יכולה לפעול בארבעה נקודות במחזור החיים של הבקשה. Inbound, בדרך פנימה, לפני שהבקשה מגיעה לשרת האחורי שלכם. Outbound, בדרך חזרה, לפני שהתגובה מגיעה ללקוח. Back End, ממש לפני שהבקשה מגיעה לשירות שלכם. ובשגיעה, כשמשהו נכשל. פעולות נכנסות נפוצות כוללות אימות אסימוני JWT לבדיקת זהות הקורא, בדיקת מפתחות API, שכתוב כתובות URL והגבלה לפי כתובת IP.

כל זה קורה לפני שהאק-אנד שלך רואה בקשה אחת. עבור פעולות יוצאות, ניתן לשנות את גוף התגובה. ניתן למצוא ולהחליף טקסט, להסיר שדות רגישים ולשנות פורמטים. ניתן לשמור תגובות במטמון, כך שבקשות חוזרות לא יגיעו למדבק-אנד שלך. ניתן אפילו להסיר כותרות שחושפות מידע פנימי. הנה דוגמה מוחשית. נניח שהאפ-אנד שלך מחזיר תיאורי מוצרים עם המילה כחול בכל מקום. אתה רוצה לעשות מיתוג מחדש ולהשתמש בצהוב במקום. במקום לשנות את קוד היי-בק-אנד, אתה מוסיף מדיניות יציאה אחת. מצא, כחול, החלף בצהוב. וזהו, הבק-אנד שלך לעולם לא משתנה. מדיניות הגבלת קצב ומכסות מגינה על היי-בק-אנד שלך מפני שימוש לרעה. אם אפליקציה של מישהו משתבשת ומתחילה להפציץ את ה-API שלך עשרת אלפים פעמים בשנייה, המדיניות מתערבת ואומרת, ה-A. הבק-אנד שלך נשאר תקין. זקוק ללוגיקה מתקדמת. ניתן לכתוב ביטויי C-H, מותאמים אישית בתוך מדיניות. הם עוברים הידור לטובת ביצועים. לכן, אין עלות זמן ריצה. ניתן לבצע בדיקת תפקידי משתמש, לחשב מגבלות קצב דינמיות או לשנות תגובות באופן מותנה בהתאם לחותרות הבקשה.

השורה התחתונה היא זו. מדיניות מאפשרת לך לשלוט באופן שבו האפיס שלך מתנהגים מבלי לגעת בקוד שמריץ אותם. זה אומר שינויים מהירים יותר, פחות פריסות ופחות סיכון. מוצרים ומנויים, הריזת EPIs עבור צרכנים. כעת האפיס שלך מוגדרים, המדיניות במקום, וה-Gataway עובד בצורה חלקה. אבל, איך נותנים ללקוחות שונים גישה לדברים שונים? כאן נכנסים לתמונה מוצרים ומנויים. באפים, אתה מקבץ EPIs למה שהוא שנקרא מוצר. תחשוב על זה כחבילה. ייתכן שיהיה לך מוצר במסלול חינמי שכולל רק את האפיס הבסיסיים שלך. אולי רק גישת קריאה בלבד, ואז מוצר פרימיום שכולל הכל, כולל פעולות כתיבה ונקודות קצה של מנהל. מפתחים לא נרשמים לאפיס בודדים, הם נרשמים למוצר. כשהם נרשמים, הם מקבלים מפתח מנוי. למעשה, שני מפתחות, כדי שתוכל להחליף אחד בלי זמן השבטה. המפתח הזה הוא הכרטיס שלהם לשימוש בכל API באותו מוצר. אתה שולט באופן שבו מנויים עובדים. מוצרים יכולים לדרוש אישור. אתה יכול לאשר ידנית כל מנוי, או שהם יכולים להיות פתוחים לשירות עצמי. כל אחד נרשם ומקבל גישה מיידית.

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

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

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

כל הכוח הזה חסר תועלת אם ההבטחה לא נעולה. אז בואו נדבר על איך APIM מטפל בזהות, גישה וסודות. APIM תומך בשיטות אימות מרובות. הפשוטה ביותר היא מפתחות מנוי, עליהם דיברנו קודם. אבל עבור מערכות ייצור, תרצו משהו חזק יותר, כמו OOF 2.0, הסימוני JWT, אישורי לקוח או סינון IP. אתם משלבים אותם בשכבות בהתאם לרמת הרגישות של ה-API שלכם. עבור סביבת ייצור, הפרקטיקה המומלצת היא להשתמש ב-OF 2.0 עם Entra ID. כך זה עובד. אפליקציית הלקוח מקבלת אסימון מ-Entra ID ושולחת אותו עם בקשת ה-API. APIM מאמת את האסימון על ידי בדיקת החתימה, המנפיק, הקהל ותוקף האסימון. אם הוא תקף, APIM מעביר את הבקשה לבקנד שלכם, כולל האסימון. הבקנד שלכם סומך על כך כי APIM כבר רימת אותו, לכן אין צורך באימות חוזר. זה דבר אחד פחות שכל שירות צריך לטפל בו. כעת, בואו נדבר על סודות. מפתחות API, מחרוזות חיבור, אישורים אתם לא רוצים שהם יהיו מוטמעים בקוד בקבצי מדיניות או בניהול גרסאות. לאפים יש תכונה הנקראת ערכים בעלי שם, Named Values. אתם מאחסנים סודות באופן מרכזי באפים ומתייחסים עליהם בשמם במדיניות שלכם.

הערך הממשי לעולם לא מופיע בקוד המדיניות שלכם. יתרה מכך, ניתן לחבר ערכים בעלי שם ל-Azure Key Vault. הסודות נשארים מוצפנים בקי וולט, והפים הושך אותם בזמן ריצה. אף אחד, אפילו לא צוות הדבופס שלכם, לא רואה את ערך הסוד הממשי. כשצריך להחליף מפתח, מעדכנים אותו בקי וולט, והפים מזהה את השינוי באופן אוטומטי. API תומך גם בזהויות מנוהלות, Managed Identities. זה מאפשר להפים לבצע אימות מול שירותי Azure אחרים כמו Key Vault או API אחורי ללא יחסו נישורים. Azure מנהלת את הזהות, אז אתם רק צריכים להעניק הרשאות. ועבור בידוד רשת, ניתן לפרוס את API בתוך רשת וירטואלית. זהו שכבת הפרימיום, או להשתמש ב-Azure Front Door. הנקודה היא ששירותי הבקנד שלכם לא צריכים להיחשף ישירות לאינטרנט. API הוא הדבר היחיד שהעולם החיצון רואה. גישה מרובדת זו בונה הגנה לעומק. אימות בשער, סודות בכספת ובידוד רשת סביב הבקנד שלכם. כל שכבה מחזקת את הבאה אחריה. שכבות תמחור איזו מהן מתאימה לכם? אז כמה זה עולה? בואו נעבור על השכבות. שכבת הצריכה, consumption.

תשלום לפי קריאת API ללא עלות חודשית קבועה. מושלם לאומסים נמוכים או משתנים, כמו כשאתם רק בשלב יצירת אבטיפוס. אם אתם עדיין לא בטוחים מה אתם צריכים, תתחילו כאן. שכבת המפתחים מציעה עלות חודשית קבועה ונמוכה של כף מינוס 50 דולר. סט תכונות מלא, אך ללא SLA. אידיאלי לסביבות פיתוח ובדיקות. אתם מקבלים את כל מה שיש בפרימיום, אך לא ניתן להשתמש בו לייצור. שכבת הבייסיק היא שכבת כניסה לייצור. תפוקה נמוכה יותר ללא תמיכה ברשת וירטואלית. אך אתם מקבלים SLA אמיתי. טוב לחילים פנימיים או פרויקטים קטנים שבהם רשת פרטית אינה קריטית. רוב העסקים בוחרים בשכבת הסטנדרד. היא כוללת תמיכה ברשת וירטואלית, זמינות של 99.95% ותפוקה טובה. אם אתם מריצים ממשקי API קריטיים לעסק, כנראה שכאן תשתקו. שכבת הפרימיום מיועדת לארגונים גלובליים שזקוקים לאמינות מקסימלית ורשת פרטית. פריסה מרובת אזורים, שער מאוכסן עצמית, זמינות של 99.99% והזרקה מלאה לרשת וירטואלית. המחיר מתחיל ביכם מינוס 2,700 דולר לחודש ליחידה. מייקרוסופט הציגה גם שכבות V2, Basic V2, Standard V2 ופרימיום V2.

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

איך הצוות ניהול API לפניו תשנה את רמת ההבטחה שלכם ואת היכולת לנטר שימוש. עצם המחשבה על התרגיל הזה תראה לכם את הערך שבדבר.

תודה שהקשבתם.