מה זה Apigee Edge?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך מאפשרים גישה לשירותים דרך Apigee Edge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעקב וניתוח בקצוות

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

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

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

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

סביבת הפיתוח של Edge

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

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

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

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

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

  

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

  

מונטיזציה

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

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

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

טעמים של Edge

יש כמה גרסאות של Apigee Edge:

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

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

• טעמים של Apigee
• מהו Apigee Hybrid?

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

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

רשימה של ההבדלים בין הגרסאות מופיעה במאמר השוואה בין מוצרי Apigee.

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

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

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