WEBVTT

00:00:00.000 --> 00:00:02.540
ברוכים הבאים לפרק נוסף של פניני ידע מבית מייקרוסופט.

00:00:02.620 --> 00:00:04.340
אני המערך שלכם, מירקופיטרס.

00:00:04.420 --> 00:00:06.160
הנושא של היום הוא כזה שכמעט כולם שמרו עליו,

00:00:06.280 --> 00:00:08.420
אך מעטים באמת מבינים ממשקי תכנות יישומים, API's.

00:00:08.480 --> 00:00:10.820
כנראה שמעתם את המונח הזה נזרק להעביר לא מעט פעמים.

00:00:11.000 --> 00:00:12.940
זו אחת מאותן מילים טכנולוגיות שאנשים משתמשים בהן

00:00:12.940 --> 00:00:14.740
כשהם רוצים להישמע כאילו הם מבינים על מה הם מדברים.

00:00:14.920 --> 00:00:17.300
אבל הנה העניין, API's הם למעשה דבר פשוט.

00:00:17.300 --> 00:00:19.860
הם פשוט דרך שבה פיסת תוכנה אחת מדברת עם אחרת.

00:00:20.000 --> 00:00:21.680
הטלפון שלכם מבקש נתונים משרה.

00:00:21.880 --> 00:00:23.120
השרת שולח אותם בחזרה.

00:00:23.300 --> 00:00:24.060
זו קריאת API.

00:00:24.320 --> 00:00:27.140
עכשיו דמיינו שיש לכם 20 ממשקי API, או 50, או 100.

00:00:27.280 --> 00:00:29.200
כל אחד מהם עשוי להשתמש בעימות שונה,

00:00:29.360 --> 00:00:31.880
במגבלות קצב שונות, ובטיעות שונה אם בכלל יש כזה.

00:00:32.000 --> 00:00:35.080
פתאום, מה שהתחיל כשיחה פשוטה בין שתי אפליקציות

00:00:35.080 --> 00:00:36.140
הופך לחאוס מוחלט.

00:00:36.240 --> 00:00:39.240
ללא מנהל מרכזי, כל צוות ממציא את הגלגל מחדש.

00:00:39.240 --> 00:00:41.080
צוות אחד בונה מערכת עימות משלו,

00:00:41.240 --> 00:00:42.880
אחר בונה מערכת רישום אירועי משלו.

00:00:42.980 --> 00:00:44.720
פרצות הבטחה מופיעות בכל מקום.

00:00:44.900 --> 00:00:46.940
מפתחים מתבלבלים לגבי מה עושה כל API,

00:00:47.300 --> 00:00:50.200
ואין לכם תצוגה אחת של מה שבאמת קורה בכל המערכת שלכם.

00:00:50.340 --> 00:00:52.420
ניהול ה-API של Azure פותר את זה,

00:00:52.520 --> 00:00:54.280
ומעניק לכם מרכז בקרה אחד.

00:00:54.280 --> 00:00:57.900
חישבו על זה כי מגדל פיקוח אווירי עבור ממשקי ה-API שלכם.

00:00:57.980 --> 00:01:00.340
עד סוף הפרק הזה, תבינו מה זה באמת,

00:01:00.500 --> 00:01:03.180
למה זה חשוב, ואיך כל החלקים מתחברים יחד.

00:01:03.180 --> 00:01:05.640
קחו את הקפה שלכם ובואו נצלול פנימה.

00:01:05.740 --> 00:01:08.580
הבעיה יותר מדי ממשקי API ללא שליטה.

00:01:08.720 --> 00:01:10.460
הנה המציאות של תוכנה מודרנית.

00:01:10.600 --> 00:01:13.380
לפני עשר שנים, כנראה הייתה לכם אפליקציה אחת גדולה,

00:01:13.500 --> 00:01:16.180
מונוליטית, מסד נתונים אחד, API אחד, פשוט.

00:01:16.180 --> 00:01:20.020
היום, אותה אפליקציה עשויה להיות מפורקת לעשרות מיקרו שירותים.

00:01:20.160 --> 00:01:23.660
כל שירות מטפל בדבר אחד, חשבונות משתמש, תשלומים, מלאי,

00:01:23.780 --> 00:01:25.680
התראות וכל אחד חושף API משלו.

00:01:25.800 --> 00:01:29.340
פתאום, יש לכם עשר, חמישים או מאה נקודות כניסה שונות למערכת שלכם.

00:01:29.480 --> 00:01:32.760
עכשיו דמיינו שאתם מפתחים שמנסים לבנות משהו שמשתמש באפיס האלה.

00:01:32.880 --> 00:01:35.620
עליכם למצוא כל אחד מהם ולהבין את אופן האימות של כל אחד.

00:01:35.820 --> 00:01:38.900
חלק משתמשים במפתחות API, חלק באורף, וחלק לא משתמשים בכלום.

00:01:38.900 --> 00:01:42.100
אתם צריכים לטפל במגבלות הקצב באופן ידני או להסתכן בחסימה.

00:01:42.200 --> 00:01:44.640
עליכם להבין את פורמט הנתונים שכל אחד מצפה לו.

00:01:44.820 --> 00:01:47.640
זה מתיש, וזה נהיה גרוע יותר מהזווית התפעולית.

00:01:47.640 --> 00:01:51.760
ללא שאר מרכזי, כל צוות צריך להוסיף הבטחה ורישום אירועים לשירות שלו באופן ידני.

00:01:51.900 --> 00:01:54.480
יש צוותים שעושים זאת היטב, אחרים שוכחים לטעת שגיאות.

00:01:54.680 --> 00:01:56.280
חלק לא מבצעים אימות כלת כלל.

00:01:56.440 --> 00:01:59.320
זה לא עקבי ונוטה לשגיאות, סיוט הבטחה שמחכה לקרות.

00:01:59.320 --> 00:02:01.600
עמידה בתקנים הופכת לכמעט בלתי אפשרית.

00:02:01.760 --> 00:02:06.380
צריכים להוכיח מי ניגש למה ומתי, שיהיה לכם בהצלחה לחלץ דוחות ביקורת מ-20 שירותים שונים,

00:02:06.580 --> 00:02:07.760
כשכל אחד עם פורמט הרישום שלו.

00:02:07.760 --> 00:02:11.060
צריך לדעת כמה קריאות API המערכת שלך הטיפלה בהן בחודש שעבר.

00:02:11.220 --> 00:02:13.960
אתה מחבר יחד נתונים מתרייסר לוחות מכוונים שונים.

00:02:14.140 --> 00:02:14.840
הנה העניין.

00:02:15.000 --> 00:02:16.860
ככל שאתה גדל, זה לא רק מציק.

00:02:17.040 --> 00:02:17.900
זה פשוט קורס.

00:02:17.900 --> 00:02:21.320
אי אפשר להוסיף עוד מפתחים, שירותים ולקוחות בלי נקודת בקרה מרכזית.

00:02:21.420 --> 00:02:22.700
תחשוב על זה כמו על בניין.

00:02:22.840 --> 00:02:24.920
תאר לעצמך שלכל חדר יש מנעול שונה.

00:02:25.060 --> 00:02:26.520
אין דלפק קבלה או מדריך.

00:02:26.700 --> 00:02:31.060
מבקרים משוטטים ומנסים למצוא את הדלת הנכונה, מתסכלים ובסוף מבטרים.

00:02:37.760 --> 00:02:40.360
אז מה זה בדיוק Azure API Management?

00:02:40.640 --> 00:02:42.260
הנה ההגדרה הפשוטה ביותר.

00:02:42.400 --> 00:02:46.360
זהו שירות מנוהל שיושב בין ה-API של ה-Back-End שלך לבין האפליקציות,

00:02:46.480 --> 00:02:48.360
אתרים, מכשירים ושותפים שצורכים אותם.

00:02:48.360 --> 00:02:50.240
אבל העניין הוא שזה לא רק פרוקסי.

00:02:50.360 --> 00:02:52.120
פרוקסי רק מעביר תעבורה וזהו.

00:02:52.240 --> 00:02:55.480
Azure API Management מכסה את כל מחזור החיים של ה-API שלך.

00:02:55.580 --> 00:02:58.340
פרסום, הבטחה, ניטור ובסוף גם הוצאה משימוש.

00:02:58.520 --> 00:02:59.660
זהו מרכז בקרה מלא.

00:02:59.860 --> 00:03:01.720
בואו נחלק את זה לשלושה רכיבים עיקריים.

00:03:01.880 --> 00:03:02.980
הראשון הוא הגאטאווי.

00:03:03.180 --> 00:03:04.360
זו דלת הכניסה הראשית.

00:03:04.500 --> 00:03:07.040
כל בקשה נכנסת מאפליקציה או אתר מגיעה קודם לגייטווי

00:03:07.040 --> 00:03:08.640
לעולם לא ישירות למד-Back-End שלך.

00:03:08.780 --> 00:03:10.120
הגאטאווי מאבד את הבקשה,

00:03:10.120 --> 00:03:11.440
אוכף מדיניות שהגדרת,

00:03:11.680 --> 00:03:14.340
אוסף מדדים ואז מעביר אותה לשירות ה-Back-End הנכון.

00:03:14.460 --> 00:03:16.020
תחשוב על זה כשוטר תנועה.

00:03:16.120 --> 00:03:18.420
הבא בתור הוא מישור הניהול Management Plane.

00:03:18.580 --> 00:03:19.700
כאן אתה מגדיר הכל.

00:03:19.820 --> 00:03:22.860
את ה-API, המדיניות, המוצרים והמינויים שלך.

00:03:23.020 --> 00:03:24.500
אתה עושה זאת דרך פורטל Azure,

00:03:31.720 --> 00:03:32.440
פורטל המפתחים.

00:03:32.600 --> 00:03:34.420
זהו אתר בשירות עצמי שבו מפתחים,

00:03:34.520 --> 00:03:35.480
פנימיים וחיצוניים,

00:03:35.680 --> 00:03:37.140
יכולים לגלות את ה-API שלך,

00:03:37.320 --> 00:03:37.840
לקרות תיעוד,

00:03:38.020 --> 00:03:39.000
לקבל מפתחות מינוי

00:03:39.000 --> 00:03:41.140
ואפילו לבדוק קריאות API ישירות בדפדפן.

00:03:41.140 --> 00:03:43.260
לא עוד שליחת קבצי PDF הלוך ושוב.

00:03:43.420 --> 00:03:44.820
הנה אנלוגיה שעוזרת להבין.

00:03:44.960 --> 00:03:46.320
תחשוב על שדה תעופה מודרני.

00:03:46.440 --> 00:03:47.880
הגאטאווי הוא מסלול ההמראה.

00:03:48.020 --> 00:03:49.480
כל מטוס נוחת שם קודם.

00:03:49.640 --> 00:03:51.340
מישור הניהול הוא מגדל הפיקוח.

00:03:51.520 --> 00:03:52.620
הוא מכוון את התנועה,

00:03:52.620 --> 00:03:54.280
קובע חוקים ומנטר הכל.

00:03:54.420 --> 00:03:56.300
ופורטל המפתחים הוא לוח המידע.

00:03:56.380 --> 00:03:57.860
טייסים בודקים אותו לפני הטיסה

00:03:57.860 --> 00:03:59.160
ויכולים למצוא את כל המידע

00:03:59.160 --> 00:04:00.720
שהם צריכים בלי לדבר עם אף אחד.

00:04:00.720 --> 00:04:02.540
עכשיו, בואו נתמקד בגאטאווי.

00:04:02.680 --> 00:04:05.100
זה החלק שהאפליקציות שלך באמת מדברות איתו

00:04:05.100 --> 00:04:06.360
ושם קורה הקסם האמיתי.

00:04:06.520 --> 00:04:09.080
הגאטאווי, דלת הכניסה של ה-API שלך.

00:04:09.260 --> 00:04:10.400
בואו נדבר על הגאטאווי

00:04:10.400 --> 00:04:12.940
כי זה החלק שהאפליקציות שלך באמת מדברות איתו.

00:04:13.040 --> 00:04:14.320
כל בקשה מאפליקציה לנייד,

00:04:14.320 --> 00:04:15.700
אתר אינטרנט או מכשיר IOT

00:04:15.700 --> 00:04:16.760
מגיעה קודם כל לשער

00:04:16.760 --> 00:04:18.480
לעולם לא ישירות לשרת האחורי שלכם.

00:04:18.620 --> 00:04:19.680
זו בדיוק כל המטרה.

00:04:19.880 --> 00:04:22.600
השער יושב בחזית ומשמש כנקודת כניסה יחידה.

00:04:22.600 --> 00:04:25.560
השער יכול להכיל מדיניות לפני העברת הבקשה הלאה.

00:04:25.660 --> 00:04:28.180
מדיניות היא כללים שאתם כותבים ב-XML או JSON

00:04:28.180 --> 00:04:29.960
כמו הגבלת קצב, סינון IP,

00:04:30.200 --> 00:04:31.980
כתיבה מחדש של כותרות ובדיקות אימות.

00:04:32.080 --> 00:04:33.720
הכל מבלי לשנות אפילו שורה אחת

00:04:33.720 --> 00:04:34.980
בקוד השרת האחורי שלכם.

00:04:35.080 --> 00:04:36.120
הנה דוגמה מוחשית.

00:04:36.120 --> 00:04:39.200
נניח שיש לכם מסלול חינמי ומסלול פרימיום ל-API שלכם.

00:04:39.320 --> 00:04:40.760
בעזרת מדיניות, אתם יכולים להגביל

00:04:40.760 --> 00:04:42.280
משתמשים חינמיים לחמש בקשות בדקה

00:04:42.280 --> 00:04:43.680
בזמן שמשתמשי פרימיום מקבלים מאה.

00:04:43.680 --> 00:04:45.960
השערת האחורי שלכם לעולם לא ידע את ההבדל.

00:04:46.040 --> 00:04:47.220
הוא פשוט מאבד בקשות.

00:04:47.440 --> 00:04:48.800
השער מטפל באכיפה.

00:04:48.920 --> 00:04:51.000
השער מטפל גם במטמון, קאשינג.

00:04:51.100 --> 00:04:52.600
אם נתונים מתבקשים שוב ושוב,

00:04:52.860 --> 00:04:54.760
כמו רשימת מוצרים שכמעט לא משתנה,

00:04:55.000 --> 00:04:57.400
השער יכול לשמור את התגובה ולהגיש אותה ישירות.

00:04:57.560 --> 00:04:59.340
אין צורך להטריד את השערת האחורי כלל.

00:04:59.540 --> 00:05:02.360
מה שאומר תגובות מהירות יותר ופחות אומס על השערתים שלכם.

00:05:02.480 --> 00:05:03.720
הוא יכול גם להמיר נתונים.

00:05:03.720 --> 00:05:05.740
השערת האחורי שלכם עשוי להחזיר XMR,

00:05:05.980 --> 00:05:07.520
אבל האפליקציה שלכם מצפה לג'סון.

00:05:07.640 --> 00:05:09.540
השער יכול להמיר את זה תוך כדי תנועה.

00:05:09.660 --> 00:05:11.480
השערת האחורי שלכם לא צריך להשתנות,

00:05:11.560 --> 00:05:13.000
וגם האפליקציה לא צריכה להשתנות.

00:05:13.160 --> 00:05:14.540
השער מטפל בתרגום,

00:05:14.720 --> 00:05:17.920
והוא מתעד כל קריאה, כל בקשה, כל תגובה, כל שגיאה.

00:05:18.040 --> 00:05:20.400
אתם מקבלים נתיב ביקורת מלא של מי קרה למה,

00:05:20.540 --> 00:05:21.460
מתי ומה קרה.

00:05:21.620 --> 00:05:24.280
זה לבדו מצדיק את כל המאמץ עבור ציוט לתקנים.

00:05:24.280 --> 00:05:25.660
אם יש לכם קהל גלובלי,

00:05:25.860 --> 00:05:28.020
אתם יכולים לפרוס את השער במספר הזורים.

00:05:28.140 --> 00:05:30.280
התעבורה מנוטבת אוטומטית לקרוב ביותר,

00:05:30.480 --> 00:05:32.660
מה שנותן שיהוי נמוך יותר וחוויה טובה יותר.

00:05:32.860 --> 00:05:34.720
עוד דבר, השער מסתיר את כתובת ה-URL,

00:05:34.800 --> 00:05:36.100
האמיתית של השרת האחורי שלכם.

00:05:36.260 --> 00:05:37.840
לקוחות רואים רק את כתובת השער.

00:05:37.840 --> 00:05:40.320
שרתי Hey Back End שלכם נשארים חבויים מהאינטרנט.

00:05:40.500 --> 00:05:42.880
זהו יתרון הבטחה עצום שניתן כברירת מחדל.

00:05:43.020 --> 00:05:45.160
מדיניות, המנוע ששולט בכל דבר.

00:05:45.160 --> 00:05:47.220
אז מה לגבי אותן מדיניות שהזכרתי?

00:05:47.380 --> 00:05:49.760
הן המנוע שהופך את A-PIM לעוצמתי באמת.

00:05:49.940 --> 00:05:52.280
מדיניות משנה את התנהגות הבקשה או התגובה

00:05:52.280 --> 00:05:54.160
בלי שתצטרכו לגעת בקוד השרת האחורי.

00:05:54.280 --> 00:05:56.620
חישבו על זה כעל מעטפת סביב ה-API שלכם.

00:05:56.780 --> 00:05:58.040
כשהתעבורה זורמת דרכו,

00:05:58.040 --> 00:06:00.660
הוא יכול להוסיף, להסיר או לשנות דברים באופן אוטומטי.

00:06:00.760 --> 00:06:03.740
מדיניות יכולה לפעול בארבעה נקודות במחזור החיים של הבקשה.

00:06:03.860 --> 00:06:07.360
Inbound, בדרך פנימה, לפני שהבקשה מגיעה לשרת האחורי שלכם.

00:06:07.480 --> 00:06:10.500
Outbound, בדרך חזרה, לפני שהתגובה מגיעה ללקוח.

00:06:10.700 --> 00:06:13.520
Back End, ממש לפני שהבקשה מגיעה לשירות שלכם.

00:06:13.640 --> 00:06:15.280
ובשגיעה, כשמשהו נכשל.

00:06:15.420 --> 00:06:18.200
פעולות נכנסות נפוצות כוללות אימות אסימוני JWT

00:06:18.200 --> 00:06:20.360
לבדיקת זהות הקורא, בדיקת מפתחות API,

00:06:20.360 --> 00:06:22.960
שכתוב כתובות URL והגבלה לפי כתובת IP.

00:06:23.140 --> 00:06:25.880
כל זה קורה לפני שהאק-אנד שלך רואה בקשה אחת.

00:06:26.000 --> 00:06:28.420
עבור פעולות יוצאות, ניתן לשנות את גוף התגובה.

00:06:28.540 --> 00:06:29.920
ניתן למצוא ולהחליף טקסט,

00:06:30.020 --> 00:06:31.960
להסיר שדות רגישים ולשנות פורמטים.

00:06:32.100 --> 00:06:33.320
ניתן לשמור תגובות במטמון,

00:06:33.400 --> 00:06:35.620
כך שבקשות חוזרות לא יגיעו למדבק-אנד שלך.

00:06:35.760 --> 00:06:38.140
ניתן אפילו להסיר כותרות שחושפות מידע פנימי.

00:06:38.260 --> 00:06:39.320
הנה דוגמה מוחשית.

00:06:39.320 --> 00:06:43.060
נניח שהאפ-אנד שלך מחזיר תיאורי מוצרים עם המילה כחול בכל מקום.

00:06:43.180 --> 00:06:45.900
אתה רוצה לעשות מיתוג מחדש ולהשתמש בצהוב במקום.

00:06:46.040 --> 00:06:47.880
במקום לשנות את קוד היי-בק-אנד,

00:06:48.060 --> 00:06:49.640
אתה מוסיף מדיניות יציאה אחת.

00:06:49.760 --> 00:06:51.740
מצא, כחול, החלף בצהוב.

00:06:51.920 --> 00:06:54.160
וזהו, הבק-אנד שלך לעולם לא משתנה.

00:06:54.320 --> 00:06:57.540
מדיניות הגבלת קצב ומכסות מגינה על היי-בק-אנד שלך מפני שימוש לרעה.

00:06:57.540 --> 00:07:01.600
אם אפליקציה של מישהו משתבשת ומתחילה להפציץ את ה-API שלך עשרת אלפים פעמים בשנייה,

00:07:01.760 --> 00:07:02.960
המדיניות מתערבת ואומרת,

00:07:03.040 --> 00:07:03.200
ה-A.

00:07:03.360 --> 00:07:04.920
הבק-אנד שלך נשאר תקין.

00:07:05.120 --> 00:07:06.300
זקוק ללוגיקה מתקדמת.

00:07:06.500 --> 00:07:08.960
ניתן לכתוב ביטויי C-H, מותאמים אישית בתוך מדיניות.

00:07:09.100 --> 00:07:10.640
הם עוברים הידור לטובת ביצועים.

00:07:10.800 --> 00:07:12.240
לכן, אין עלות זמן ריצה.

00:07:12.240 --> 00:07:13.980
ניתן לבצע בדיקת תפקידי משתמש,

00:07:13.980 --> 00:07:17.900
לחשב מגבלות קצב דינמיות או לשנות תגובות באופן מותנה בהתאם לחותרות הבקשה.

00:07:18.040 --> 00:07:19.360
השורה התחתונה היא זו.

00:07:19.460 --> 00:07:24.080
מדיניות מאפשרת לך לשלוט באופן שבו האפיס שלך מתנהגים מבלי לגעת בקוד שמריץ אותם.

00:07:24.220 --> 00:07:27.260
זה אומר שינויים מהירים יותר, פחות פריסות ופחות סיכון.

00:07:27.520 --> 00:07:28.560
מוצרים ומנויים,

00:07:28.760 --> 00:07:30.620
הריזת EPIs עבור צרכנים.

00:07:30.620 --> 00:07:32.320
כעת האפיס שלך מוגדרים,

00:07:32.480 --> 00:07:33.440
המדיניות במקום,

00:07:33.640 --> 00:07:35.340
וה-Gataway עובד בצורה חלקה.

00:07:35.420 --> 00:07:38.240
אבל, איך נותנים ללקוחות שונים גישה לדברים שונים?

00:07:38.400 --> 00:07:40.500
כאן נכנסים לתמונה מוצרים ומנויים.

00:07:40.700 --> 00:07:44.040
באפים, אתה מקבץ EPIs למה שהוא שנקרא מוצר.

00:07:44.160 --> 00:07:45.380
תחשוב על זה כחבילה.

00:07:45.520 --> 00:07:49.440
ייתכן שיהיה לך מוצר במסלול חינמי שכולל רק את האפיס הבסיסיים שלך.

00:07:49.600 --> 00:07:51.140
אולי רק גישת קריאה בלבד,

00:07:51.320 --> 00:07:53.040
ואז מוצר פרימיום שכולל הכל,

00:07:53.040 --> 00:07:55.660
כולל פעולות כתיבה ונקודות קצה של מנהל.

00:07:55.760 --> 00:07:57.820
מפתחים לא נרשמים לאפיס בודדים,

00:07:58.020 --> 00:07:59.040
הם נרשמים למוצר.

00:07:59.200 --> 00:08:01.400
כשהם נרשמים, הם מקבלים מפתח מנוי.

00:08:01.520 --> 00:08:02.700
למעשה, שני מפתחות,

00:08:02.700 --> 00:08:04.700
כדי שתוכל להחליף אחד בלי זמן השבטה.

00:08:04.820 --> 00:08:07.880
המפתח הזה הוא הכרטיס שלהם לשימוש בכל API באותו מוצר.

00:08:07.960 --> 00:08:09.720
אתה שולט באופן שבו מנויים עובדים.

00:08:09.900 --> 00:08:11.360
מוצרים יכולים לדרוש אישור.

00:08:11.580 --> 00:08:13.200
אתה יכול לאשר ידנית כל מנוי,

00:08:13.360 --> 00:08:15.220
או שהם יכולים להיות פתוחים לשירות עצמי.

00:08:15.220 --> 00:08:17.340
כל אחד נרשם ומקבל גישה מיידית.

00:08:17.460 --> 00:08:20.840
ניתן גם לכלול תנאים משפטיים שמשתמשים חייבים לאשר לפני ההרשמה.

00:08:21.020 --> 00:08:23.380
זה חשוב אם האפיס שלך מטפלים בנתונים רגישים.

00:08:23.520 --> 00:08:25.120
כך אתה עושה מוניטיזציה לאפיס.

00:08:25.120 --> 00:08:27.240
מוצר חינמי עם מגבלות קצב נמוכות,

00:08:27.360 --> 00:08:28.220
חמש קריאות לדקה.

00:08:28.320 --> 00:08:30.700
מוצר בתשלום עם מגבלות גבוהות יותר או יותר נקודות קצה,

00:08:30.860 --> 00:08:31.640
מאה קריאות לדקה,

00:08:31.780 --> 00:08:33.020
בתוספת גישה לתכונות פרימיום.

00:08:33.160 --> 00:08:34.700
למד BACK-אנד שלך זה לא משנה.

00:08:34.700 --> 00:08:37.900
השער עוכף את המגבלות בהתבסס על המוצר שאליו נרשם המשתמש.

00:08:38.020 --> 00:08:39.160
הנה דוגמה מהמציאות.

00:08:39.340 --> 00:08:41.060
דמיינו שאתם בונים אפליקציה לחנס.

00:08:41.280 --> 00:08:43.980
אתם יוצרים מוצר למשתתפים עם ממשקי API ללוח הזמנים,

00:08:43.980 --> 00:08:45.700
ביוגרפיות של דוברים ומפת המקום.

00:08:45.840 --> 00:08:49.060
לאחר מכן מוצר נותני חסות שכולל גם ממשקי API להפקת לידים.

00:08:49.240 --> 00:08:52.020
נותני החסות יכולים לסרוק תגי משתתפים ולקבל פרטי התקשרות.

00:08:52.020 --> 00:08:54.840
אותו עורף, BACK-אנד, מוצרים שונים, רמות גישה שונות.

00:08:54.940 --> 00:08:57.300
שני מפתחות המנוי הללו מתוכננים לצורך החלפה,

00:08:57.420 --> 00:08:57.740
rotation.

00:08:57.980 --> 00:09:00.320
אם מפתח נפגע, אתם יוצרים מפתח חדש.

00:09:00.480 --> 00:09:03.240
המפתח השני מאפשר לכם לעבור בלי להפריע לשירות.

00:09:03.240 --> 00:09:06.620
צרו מפתח חדש, עדכנו את האפליקציה וביטלו את הישן.

00:09:06.800 --> 00:09:07.640
חלק ופשוט

00:09:07.640 --> 00:09:10.380
פורטל המפתחים, שירות עצמי עבור צרכני API.

00:09:10.380 --> 00:09:12.620
אז הגדרתם את מוצרי ה-API שלכם.

00:09:12.740 --> 00:09:14.300
עכשיו מפתחים צריכים למצוא אותם.

00:09:14.440 --> 00:09:16.000
זה התפקיד של פורטל המפתחים.

00:09:16.120 --> 00:09:19.080
פורטל המפתחים הוא אתר אינטרנט המובנה בכל מופע APM.

00:09:19.240 --> 00:09:21.540
מפתחים משתמשים בו כדי לעיין ב-API שלכם,

00:09:21.720 --> 00:09:24.780
לקרוא תיעוד ולבדוק נקודות קצה באופן אינטראקטיבי ישירות בדפדפן.

00:09:24.920 --> 00:09:27.300
אין צורך בהתקנה ואין התכתבויות מיילים הלוך ושוב.

00:09:27.480 --> 00:09:29.860
אבל הנה העניין, הוא לא מפורסם כברירת מחדל.

00:09:29.960 --> 00:09:32.440
כשיוצרים את מופע ה-APM לראשונה, הפורטל קיים,

00:09:32.440 --> 00:09:33.700
אך אף אחד לא יכול לראות אותו.

00:09:33.820 --> 00:09:35.940
עליכם להתאים אותו אישית ולפרסם אותו תחילה.

00:09:36.060 --> 00:09:36.740
זה מכוון.

00:09:36.900 --> 00:09:39.160
אתם לא רוצים להציג לעולם פורטל חצי גמור.

00:09:39.320 --> 00:09:41.120
ניתן להתאים אישית צבעי מותג, לוגויים,

00:09:41.280 --> 00:09:44.000
ואפילו להתמיע תוכן וורדפרס לבלוג לצד מסמכי ה-API.

00:09:44.160 --> 00:09:47.400
הוא ניתן להתאמה אישית מלאה כדי להתאים למראה ולתחושה של החברה שלכם.

00:09:47.540 --> 00:09:49.260
הערך האמיתי הוא השירות העצמי.

00:09:49.260 --> 00:09:52.500
מפתחים נרשמים מקבלים את מפתחות המנוי שלהם אוטומטית,

00:09:52.680 --> 00:09:54.200
ומתחילים לקרוא ל-API מיד.

00:09:54.360 --> 00:09:56.340
ללא מיילים ידניים, ללא המתנה לאישור,

00:09:56.580 --> 00:09:58.860
ללא כרטיסי תמיכה עם שאלות על השגת מפתח.

00:09:59.040 --> 00:10:02.400
הם עושים זאת בעצמם, מה שמפחית משמעותית את נטל התמיכה שלכם.

00:10:02.540 --> 00:10:05.040
ניתן גם לפרסם יומני שינויים והערות גרסה.

00:10:05.040 --> 00:10:08.980
כשמעדכנים API, המפתחים רואים זאת בפורטל ללא הפתעות.

00:10:09.140 --> 00:10:12.700
הגישה יכולה להיות ציבורית לכל מי שיש לו את הכתובת,

00:10:12.940 --> 00:10:16.660
או שניתן להגביל אותה למשתמשים מהדייר ב-Enter ID שלכם.

00:10:16.860 --> 00:10:19.460
שתי האפשרויות קיימות עבור תרחישי שימוש שונים.

00:10:19.680 --> 00:10:22.940
פורטל המפתחים הוא מה שהופך את ניהול ה-API שלכם לפלטפורמה אמיתית.

00:10:23.100 --> 00:10:25.420
חישבו עליו כעל חנות הרעבה של ה-API שלכם.

00:10:25.580 --> 00:10:28.640
בלעדיו, מפתחים צריכים לחפש במסמכים ולשאול מסביב.

00:10:28.640 --> 00:10:31.420
איתו, הם מוצאים מה שהם צריכים ומתחילים לבנות.

00:10:35.260 --> 00:10:38.720
כל הכוח הזה חסר תועלת אם ההבטחה לא נעולה.

00:10:38.820 --> 00:10:42.420
אז בואו נדבר על איך APIM מטפל בזהות, גישה וסודות.

00:10:42.520 --> 00:10:44.560
APIM תומך בשיטות אימות מרובות.

00:10:44.700 --> 00:10:47.660
הפשוטה ביותר היא מפתחות מנוי, עליהם דיברנו קודם.

00:10:47.780 --> 00:10:51.380
אבל עבור מערכות ייצור, תרצו משהו חזק יותר, כמו OOF 2.0,

00:10:51.560 --> 00:10:54.080
הסימוני JWT, אישורי לקוח או סינון IP.

00:10:54.260 --> 00:10:57.160
אתם משלבים אותם בשכבות בהתאם לרמת הרגישות של ה-API שלכם.

00:10:57.160 --> 00:11:00.980
עבור סביבת ייצור, הפרקטיקה המומלצת היא להשתמש ב-OF 2.0 עם Entra ID.

00:11:01.140 --> 00:11:01.860
כך זה עובד.

00:11:02.020 --> 00:11:06.040
אפליקציית הלקוח מקבלת אסימון מ-Entra ID ושולחת אותו עם בקשת ה-API.

00:11:06.200 --> 00:11:10.600
APIM מאמת את האסימון על ידי בדיקת החתימה, המנפיק, הקהל ותוקף האסימון.

00:11:10.760 --> 00:11:14.680
אם הוא תקף, APIM מעביר את הבקשה לבקנד שלכם, כולל האסימון.

00:11:14.840 --> 00:11:19.420
הבקנד שלכם סומך על כך כי APIM כבר רימת אותו, לכן אין צורך באימות חוזר.

00:11:19.420 --> 00:11:22.040
זה דבר אחד פחות שכל שירות צריך לטפל בו.

00:11:22.120 --> 00:11:23.540
כעת, בואו נדבר על סודות.

00:11:23.740 --> 00:11:28.600
מפתחות API, מחרוזות חיבור, אישורים אתם לא רוצים שהם יהיו מוטמעים בקוד בקבצי מדיניות או בניהול גרסאות.

00:11:28.760 --> 00:11:31.360
לאפים יש תכונה הנקראת ערכים בעלי שם, Named Values.

00:11:31.500 --> 00:11:35.260
אתם מאחסנים סודות באופן מרכזי באפים ומתייחסים עליהם בשמם במדיניות שלכם.

00:11:35.400 --> 00:11:37.960
הערך הממשי לעולם לא מופיע בקוד המדיניות שלכם.

00:11:38.100 --> 00:11:41.100
יתרה מכך, ניתן לחבר ערכים בעלי שם ל-Azure Key Vault.

00:11:41.100 --> 00:11:44.420
הסודות נשארים מוצפנים בקי וולט, והפים הושך אותם בזמן ריצה.

00:11:44.500 --> 00:11:47.880
אף אחד, אפילו לא צוות הדבופס שלכם, לא רואה את ערך הסוד הממשי.

00:11:47.980 --> 00:11:52.660
כשצריך להחליף מפתח, מעדכנים אותו בקי וולט, והפים מזהה את השינוי באופן אוטומטי.

00:11:52.820 --> 00:11:55.780
API תומך גם בזהויות מנוהלות, Managed Identities.

00:11:55.940 --> 00:12:01.780
זה מאפשר להפים לבצע אימות מול שירותי Azure אחרים כמו Key Vault או API אחורי ללא יחסו נישורים.

00:12:01.920 --> 00:12:04.940
Azure מנהלת את הזהות, אז אתם רק צריכים להעניק הרשאות.

00:12:04.940 --> 00:12:08.720
ועבור בידוד רשת, ניתן לפרוס את API בתוך רשת וירטואלית.

00:12:08.900 --> 00:12:12.480
זהו שכבת הפרימיום, או להשתמש ב-Azure Front Door.

00:12:12.780 --> 00:12:17.240
הנקודה היא ששירותי הבקנד שלכם לא צריכים להיחשף ישירות לאינטרנט.

00:12:17.640 --> 00:12:20.340
API הוא הדבר היחיד שהעולם החיצון רואה.

00:12:20.460 --> 00:12:22.760
גישה מרובדת זו בונה הגנה לעומק.

00:12:22.920 --> 00:12:27.340
אימות בשער, סודות בכספת ובידוד רשת סביב הבקנד שלכם.

00:12:27.480 --> 00:12:29.680
כל שכבה מחזקת את הבאה אחריה.

00:12:29.880 --> 00:12:32.040
שכבות תמחור איזו מהן מתאימה לכם?

00:12:32.040 --> 00:12:33.260
אז כמה זה עולה?

00:12:33.260 --> 00:12:34.540
בואו נעבור על השכבות.

00:12:34.700 --> 00:12:36.060
שכבת הצריכה, consumption.

00:12:36.380 --> 00:12:38.740
תשלום לפי קריאת API ללא עלות חודשית קבועה.

00:12:38.840 --> 00:12:42.160
מושלם לאומסים נמוכים או משתנים, כמו כשאתם רק בשלב יצירת אבטיפוס.

00:12:42.300 --> 00:12:44.660
אם אתם עדיין לא בטוחים מה אתם צריכים, תתחילו כאן.

00:12:44.820 --> 00:12:48.160
שכבת המפתחים מציעה עלות חודשית קבועה ונמוכה של כף מינוס 50 דולר.

00:12:48.320 --> 00:12:49.920
סט תכונות מלא, אך ללא SLA.

00:12:50.120 --> 00:12:51.700
אידיאלי לסביבות פיתוח ובדיקות.

00:12:51.700 --> 00:12:54.500
אתם מקבלים את כל מה שיש בפרימיום, אך לא ניתן להשתמש בו לייצור.

00:12:54.660 --> 00:12:56.600
שכבת הבייסיק היא שכבת כניסה לייצור.

00:12:56.720 --> 00:12:58.940
תפוקה נמוכה יותר ללא תמיכה ברשת וירטואלית.

00:12:59.100 --> 00:13:00.400
אך אתם מקבלים SLA אמיתי.

00:13:00.560 --> 00:13:04.240
טוב לחילים פנימיים או פרויקטים קטנים שבהם רשת פרטית אינה קריטית.

00:13:04.420 --> 00:13:06.660
רוב העסקים בוחרים בשכבת הסטנדרד.

00:13:06.720 --> 00:13:11.600
היא כוללת תמיכה ברשת וירטואלית, זמינות של 99.95% ותפוקה טובה.

00:13:11.600 --> 00:13:15.360
אם אתם מריצים ממשקי API קריטיים לעסק, כנראה שכאן תשתקו.

00:13:15.520 --> 00:13:19.840
שכבת הפרימיום מיועדת לארגונים גלובליים שזקוקים לאמינות מקסימלית ורשת פרטית.

00:13:19.980 --> 00:13:25.700
פריסה מרובת אזורים, שער מאוכסן עצמית, זמינות של 99.99% והזרקה מלאה לרשת וירטואלית.

00:13:25.800 --> 00:13:28.580
המחיר מתחיל ביכם מינוס 2,700 דולר לחודש ליחידה.

00:13:28.700 --> 00:13:33.200
מייקרוסופט הציגה גם שכבות V2, Basic V2, Standard V2 ופרימיום V2.

00:13:33.200 --> 00:13:36.820
הן מפשטות את התמחור עם מכסות בקשות כלולות ותשלום על חריגה למיליון.

00:13:36.960 --> 00:13:41.700
במקום לעקוב אחרי מדדים רבים, מקבלים מכסה ברורה ומשלמים על שימוש נוסף במדרגות פשוטות.

00:13:41.760 --> 00:13:43.300
כך תבחרו את השכבה המתאימה.

00:13:43.440 --> 00:13:45.180
התחילו עם הדיבלופר לצורכי בדיקות.

00:13:45.320 --> 00:13:47.000
עברו לסטנדרד עבור סביבת הייצור.

00:13:47.180 --> 00:13:49.920
בחרו בפרימיום אם נדרש קנה מידה גלובלי או רשת פרטית.

00:13:50.060 --> 00:13:52.360
וזכרו, תמיד אפשר לשדרג שכבות מאוחר יותר.

00:13:52.360 --> 00:13:55.040
התחילו בקטן וצמחו ככל שהצרכים שלכם ישתנו.

00:13:55.180 --> 00:13:56.120
הנה מה שסקרנו.

00:13:56.240 --> 00:14:02.200
ניהול API לוקח את הקאוס של ממשקים רבים ומאחד אותם למרכז שליטה אחד לשער, מדיניות, אבטחה וחוויית מפתח.

00:14:02.400 --> 00:14:04.620
השורה התחתונה היא שזה הרבה מעבר לפרוקסי.

00:14:04.740 --> 00:14:07.920
תחשבו על זה כמו על המוח ומערכת העצבים של האקו, סיסטם של ה-API שלכם.

00:14:08.060 --> 00:14:11.240
בלעדיו, כל צוות בונה לעצמו עימות, רישום לוגים והגבלת קצב משלו.

00:14:11.240 --> 00:14:15.580
אתם מסיימים עם חוסר עקביות, פרצות אבטחה וחוסר יכולת לראות את התמונה הכוללת.

00:14:15.640 --> 00:14:21.400
איתו, אתם מקבלים עקביות, אבטחה ויכולת גידול מבלי להמציא את הגלגל מחדש לכל שירות.

00:14:21.720 --> 00:14:22.860
הנה תרגיל פשוט.

00:14:23.020 --> 00:14:28.520
חישבו על API אחד שאתם חושפים כרגע ישירות, אולי נקודת קצה של פונקציה או שירות אפליקציה.

00:14:28.680 --> 00:14:33.060
איך הצוות ניהול API לפניו תשנה את רמת ההבטחה שלכם ואת היכולת לנטר שימוש.

00:14:33.060 --> 00:14:36.140
עצם המחשבה על התרגיל הזה תראה לכם את הערך שבדבר.

00:14:41.240 --> 00:14:51.180
תודה שהקשבתם.