מה זה Apigee Edge?

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

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

הנגשת השירותים שלכם באינטרנט

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

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

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

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

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

יצירת מוצר API

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

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

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

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

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

Edge API runtime

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

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

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

ניתוח וניטור של נתונים ב-Edge

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

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

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

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

סביבת פיתוח של 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

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

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

ב-Public Cloud יש תמיכה בחשבונות בחינם ובחשבונות בתשלום. כדי להשתמש ב-Private Cloud, צריך חשבונות בתשלום.

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