מה זה Apigee Edge?

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

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

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

האצה בדיגיטל

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

הגדרת השירותים שלך כזמינים באינטרנט

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

לעיתים קרובות, חברות חושפות שירותים כקבוצה של נקודות קצה (endpoint) מסוג HTTP. לאחר מכן מפתחי אפליקציות לקוח שולחים בקשות HTTP לנקודות הקצה האלה. בהתאם לנקודת הקצה, השירות עשוי להחזיר לאפליקציית הלקוח נתונים בפורמט XML או JSON.

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

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

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

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

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

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

הפיכת השירותים לזמינים באמצעות Apigee Edge

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

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

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

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

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

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

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

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

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

יצירת מוצר API

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

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

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

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

מידע נוסף זמין במאמר ניהול מוצרי API.

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

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

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

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

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

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

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

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

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

הרכיבים של Apigee Edge

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

באיור הבא מוצגים שירותי Edge:

זמן ריצה של Edge API

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

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

מפתחי Node.js יכולים להוסיף בצורה חלקה את המודולים של Node.js ל-Edge וליצור ממשקי API ו-API של mashups. כך אפשר לנצל את היתרונות של Edge ש-Edge מספקת, החל מטרנספורמציה של הודעות, דרך אבטחה ועד לניתוח נתונים.

מעקב וניתוח נתונים של Edge

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

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

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

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

הסביבה העסקית של מפתחי Edge

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

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

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

באמצעות Apigee Edge אפשר ליצור שני סוגים של פורטלים:

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

  

• פורטל מבוסס-Drupal ראו בניית פורטל מבוסס Drupal.

  

מונטיזציה

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

התוכניות כוללות תוכניות בתשלום מראש, תוכניות של תשלום לאחר השימוש (postpay), מינויים עם עמלה קבועה, תוכניות עם תעריפים משתנים, תוכניות "freemium", תוכניות שמותאמות למפתחים ספציפיים, תוכניות שכוללות קבוצות של מפתחים ועוד. בנוסף, המונטיזציה כוללת אמצעי דיווח וחיוב.

למידע נוסף, ראו סקירה כללית בנושא מונטיזציה.

טעמים של קצה

Apigee Edge מגיע בטעמים הבאים:

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

אם אתם מתעניינים בגרסה ההיברידית של Apigee, תוכלו לעיין בנושאים הבאים ב-Apigee X:

• הטעמים של Apigee
• מה זה Apigee hybrid?

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

• יעדים מתארחים
• תוספים
• פורטלים משולבים למפתחים (הערה: יש תמיכה בפורטלים למפתחים המבוססים על Drupal)
• מעקב אחר API
• Sense

לקבלת רשימת ההבדלים בין הטעמים, אפשר לעיין במאמר השוואה בין מוצרי Apigee.

יש גם הבדלים קלים בין ממשקי ה-API, כפי שמתואר במאמר ההבדלים בין Edge for Public Cloud API לבין Private Cloud API.

ב-Public Cloud יש תמיכה בחשבונות בחינם וגם בחשבונות בתשלום. לשימוש בענן פרטי נדרשים חשבונות בתשלום.

כדי לתמוך באופן מלא בהתקנה מקומית, גרסת הענן הפרטי כוללת רכיבים כמו שרת הניהול Apigee, מסד נתונים Apache Cassandra NoSQL, שרת OpenLDAP, נתב הודעות ומעבד הודעות.