מה זה Apigee?

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

סרטון: סרטון קצר שמציג את ניהול API ב-Apigee.

ארכיטקטורה ברמה גבוהה

בתמונה הבאה מוצגת הארכיטקטורה ברמה גבוהה של Apigee:

כפי שרואים בתמונה, Apigee מורכב מהרכיבים העיקריים הבאים:

• שירותי Apigee: ממשקי ה-API שבהם משתמשים כדי ליצור, לנהל ולפרוס שרתי proxy ל-API.
• ‫Apigee runtime: קבוצה של שירותי זמן ריצה מבוססי-קונטיינרים באשכול Kubernetes ש-Google מתחזקת. כל התנועה של ממשקי ה-API עוברת דרך השירותים האלה ומעובדת על ידם.

בנוסף, Apigee משתמש ברכיבים אחרים, כולל:

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

הסברים מפורטים יותר זמינים במאמר רכיבים של Apigee.

התמונה הבאה מציגה את החיבור בין פרויקט בענן לשירותי Google ברשת פרטית של קישור בין רשתות שכנות (peering):

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

דיבורים מיותרים!

הגדרת Apigee

ואז

יצירת ה-proxy הראשון

גרסאות של Apigee

קיימות הגרסאות הבאות של Apigee:

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

האצה דיגיטלית

בסרטון הזה אפשר לראות במהירות איך Apigee עוזרת לכם להפוך לעסק דיגיטלי.

בחירה בין ניהול שירותים לבין ניהול API

בסרטון הזה מוסבר על ההבדלים החשובים בין ניהול שירותים לבין ניהול API.

איך להציע את השירותים שלכם באינטרנט

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

חברות רבות חושפות שירותים כקבוצה של נקודות קצה ב-HTTP. מפתחים של אפליקציות לקוח שולחים בקשות HTTP לנקודות הקצה האלה. בהתאם לנקודת הקצה, השירות עשוי להחזיר נתונים בפורמט XML או JSON לאפליקציית הלקוח.

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

בתמונה הבאה מוצג סוג המודל הזה:

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

• אבטחה: איך תגבילו את הגישה לשירותים שלכם כדי למנוע גישה לא מורשית?
• תאימות: האם השירותים שלכם פועלים בפלטפורמות ובמכשירים שונים?
• יכולת מדידה: איך אפשר לנטר את השירותים כדי לוודא שהם זמינים?
• ועוד הרבה שיקולים אחרים

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

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

הפיכת שירותים לזמינים דרך Apigee

‫Apigee מאפשר לכם לספק גישה מאובטחת לשירותים שלכם באמצעות API מוגדר היטב שפועל באופן עקבי בכל השירותים, ללא קשר לאופן ההטמעה של השירות. API עקבי:

• מאפשר למפתחי אפליקציות להשתמש בשירותים שלכם בקלות.
• מאפשר לשנות את ההטמעה של השירות לקצה העורפי בלי להשפיע על ה-API הציבורי.
• מאפשר לכם ליהנות מהניתוח, מפורטל המפתחים ומאפשרויות אחרות שמוטמעות ב-Apigee.

בתמונה הבאה מוצגת ארכיטקטורה שבה Apigee מטפל בבקשות מאפליקציות לקוח לשירותי הקצה העורפי שלכם:

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

מפתחי אפליקציות שולחים בקשות HTTP ל-proxy ל-API, ולא ישירות לשירותים שלכם. לכן, המפתחים לא צריכים לדעת דבר על ההטמעה של השירותים שלכם. כל מה שהמפתחים צריכים לדעת הוא:

• כתובת ה-URL של נקודת הקצה של proxy ל-API.
• כל פרמטר של שאילתה, כותרת או גוף שמועבר בבקשה.
• כל פרטי הכניסה הנדרשים לאימות ולהרשאה.
• הפורמט של התגובה, כולל פורמט נתוני התגובה, כמו XML או JSON.

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

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

מידע נוסף מופיע במאמר הסבר על ממשקי API ועל שרתי proxy של API.

יצירת מוצר API

שרת proxy ל-API הוא נקודת הקצה של HTTP ב-Apigee שמפתחים משתמשים בה כדי לגשת לשירותי ה-Backend שלכם. בדרך כלל לא מאפשרים גישה לשרתי proxy ספציפיים ל-API, אלא מקבצים שרת proxy אחד או יותר ל-API במוצר API.

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

יש לכם גמישות רבה כשאתם יוצרים מוצרי API. לדוגמה, כמה מוצרי API יכולים לחלוק את אותו שרת proxy ל-API. באיור הבא מוצגים שלושה מוצרי API. שימו לב שכל המוצרים מאפשרים גישה ל-proxy ל-API 3, אבל רק מוצר א' מאפשר גישה ל-proxy ל-API 1.

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

מידע נוסף מופיע במאמר בנושא יצירת מוצרי API.

איך מאפשרים לאפליקציה בצד הלקוח לגשת למוצר API

כ שמפתחי אפליקציות מחליטים שהם רוצים לגשת לשירותים שלכם, הם צריכים קודם לרשום את אפליקציית הלקוח שלהם במוצר ה-API שלכם.

לאחר ההרשמה, מפַתח אפליקציות מקבל מפתח API, והוא צריך לכלול אותו בכל בקשה ל-proxy ל-API שכלול במוצר ה-API. המפתח הזה מאומת, ואם האימות מצליח, הבקשה מקבלת גישה לשירות לקצה העורפי.

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

אתם מחליטים איך לטפל בבקשות הרשמה ממפתחים כדי לגשת למוצרי ה-API שלכם. באמצעות Apigee Developer Services, אפשר להפוך את תהליך הרישום לאוטומטי, או להשתמש בתהליך ידני כדי לשלוט בגישה.

יצירת מוצרי API והפיכתם לזמינים למפתחים

1. יוצרים פרוקסי אחד או יותר של API שממפים כתובות URL שזמינות לציבור לשירותי הקצה העורפי.
2. יוצרים מוצר API שכולל את שרתי ה-proxy ל-API.
3. פריסת שרתי proxy ל-API ומוצר API.
4. מודיעים למפתחים שמוצר ה-API זמין.

אחרי שמפתחי אפליקציות יודעים על הזמינות של מוצר ה-API שלכם, הם:

1. לרשום את אפליקציות הלקוח שלהם במוצר ה-API שלכם.
2. מקבלים מפתח API למוצר ה-API.
3. שליחת בקשות לשירותים באמצעות שרתי proxy ל-API (שנכללים בחבילת מוצר ה-API) והעברת מפתח ה-API עם כל בקשה.

רכיבים של Apigee

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

בתמונה הבאה מוצגת הארכיטקטורה ברמה גבוהה של Apigee:

Apigee runtime

שירותי Apigee מיועדים ליצירה ולשימוש בממשקי API, בין אם אתם בונים שרתי proxy ל-API כספקי שירותים או משתמשים בממשקי API, בערכות SDK ובשירותים נוחים אחרים כמפתחי אפליקציות.

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

ניתוח נתונים ומעקב ב-Apigee

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

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

בממשק המשתמש של Apigee אפשר לראות כמה מדדים ומאפיינים בדפדפן, כמו שמוצג באיור הבא:

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

הסביבה של מפתחים ב-Apigee

‫Apigee מספק שירותים למפתחים שמאפשרים לכם:

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

כל לקוח של Apigee יכול ליצור פורטל מפתחים משלו בענן.

ב-Apigee אפשר ליצור שני סוגים של פורטלים:

• פורטל משולב שאפשר להקצות לו הרשאות באופן מיידי.

  

• פורטל מבוסס Drupal שמאפשר התאמה אישית מלאה.