מה זה 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: מספקים פונקציות של ניהול זהויות, רישום ביומן, ניתוח נתונים, מדדים וניהול פרויקטים.
• שירותי קצה עורפי: האפליקציות משתמשות בהם כדי לספק גישה לנתונים בזמן ריצה עבור שרתי ה-proxy של ה-API.

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

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

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

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

הגדרת Apigee

ואז

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

גרסאות של Apigee

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

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

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

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

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

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

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

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

חברות חושפות לעיתים קרובות שירותים כקבוצה של נקודות קצה (endpoint) של 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.

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

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

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

יצירת מוצר API

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

מוצר API הוא חבילה של שרתי proxy ל-API בשילוב עם תוכנית שירות. תוכנית השירות הזו יכולה להגדיר מגבלות גישה לפרוקסי של API, לספק אבטחה, לאפשר מעקב וניתוח ולספק תכונות נוספות. מוצרי 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 שזמינות לציבור לשירותי ה-Backend.
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 ולניהול של מפתחי אפליקציות ואפליקציות לקוח. It offloads many common management concerns from your backend services. כשמוסיפים 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 שמאפשר התאמה אישית מלאה.