כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
ארגון הוא המאגר ברמה העליונה ב-Apigee Edge. הוא מכיל את כל שרתי ה-proxy של ה-API והמשאבים הקשורים. בהמשך המאמר הזה נדון לגבי ארגונים יותר לעומק, אבל הנה כמה נקודות מעשיות:
- כברירת מחדל, שם הארגון שלכם מופיע בכתובת ה-URL שמשמשת לשרת proxy ל-API, כפי שמתואר במאמר מידע על מארחים וירטואליים.
לדוגמה:
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- שם הארגון שלך מופיע בכתובת ה-URL של ממשק המשתמש לניהול Edge. לדוגמה, כתובת ה-URL הבאה מציגה את שרתי ה-proxy של ה-API עבור הארגון
docs:
- יכול להיות שיצרת רק ארגון אחד, אבל אפשר להשתייך לארגונים אחרים כמשתמש או כאדמין עם הרשאות ספציפיות. בממשק המשתמש לניהול Edge, אם אתם שייכים ליותר מארגון אחד, תוכלו לעבור לארגון אחר כפי שמתואר במאמר מעבר בין הארגונים.
- כשמתקשרים באמצעות ה-Management API כמשתמשים בתפקיד 'אדמין ארגוני', הארגון הוא חלק מהנתיב ברוב הקריאות. לדוגמה, הבקשה הבאה
מסוג cURL של ממשק API לניהול מחזירה רשימה של כל שרתי ה-proxy של ה-API בארגון:
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
סרטון: אפשר לצפות בסרטון קצר עם הסבר על האופן שבו ארגונים תומכים בארכיטקטורה מרובת דיירים (multi-tenancy) לניהול API.
רכיבים בארגון
כשיוצרים חשבון Edge, Edge יוצר עבורך ארגון באופן אוטומטי. לאחר יצירת ה-API, אפשר להוסיף משתמשים לארגון, ליצור שרתי proxy של API ומוצרי API ולרשום מפתחים ואפליקציות.
בתמונה הבאה מוצגים הרכיבים העיקריים של המודל הארגוני של Edge. המודל הזה מגדיר את הקשר בין ממשקי ה-API, מוצרי ה-API, האפליקציות ומפתחי האפליקציות שלך ב-Edge.
במודל הזה לא מוצגות כל התכונות של Apigee Edge. אם משתמשים במונטיזציה, המודל יכלול רכיבים נוספים. למידע נוסף, ראו סקירה כללית בנושא מונטיזציה. אפשר לקרוא מידע נוסף על ניהול חברות ומפתחים באמצעות מונטיזציה במאמר ניהול חברות ומפתחים.
שמות ארגונים
שם הארגון הוא:
- ארגון הערכה:
username-eval - ארגון בתשלום: מוגדר על ידי המשתמש בזמן ניהול ההקצאות הראשוני
לאחר שארגון נוצר, אי אפשר לשנות את שמו.
שם הארגון הופך לחלק מכתובת ה-URL של שרתי ה-proxy של ה-API, וכחלק מכתובת ה-URL כששולחים בקשה ל-Edge Management API. לדוגמה, כתובת URL אופיינית שמשמשת לצורך גישה לשרת proxy של API היא:
http://org-name-env.apigee.net/v1/weather/forecastrss
איפה:
- org-name הוא שם הארגון שלך.
- env הוא סביבת הפריסה של שרת proxy ל-API, שהוא סביבת בדיקה או ייצור.
לדוגמה:
http://myorg-test.apigee.net/v1/weather/forecastrss
רכיבים בארגון
בטבלה הבאה מתוארים רכיבי המודל הארגוני לעומק:
| רכיב | התיאור |
|---|---|
|
ארגון |
כל חשבון Apigee ממופה לארגון אחד או יותר ב-Apigee Edge. הארגון מכיל ייצוג של כל הרכיבים, כולל שרתי proxy של API, מוצרי API, חבילות API, אפליקציות ומפתחים. בעלי חשבונות אינם מוגבלים לארגון אחד. בעלי חשבונות מסוימים עשויים להגדיר או להיות חברים במספר ארגונים שתומכים בקהילות שונות של מפתחי אפליקציות. |
| סביבה | הקשר לביצוע בזמן ריצה לשרתי proxy של API בארגון. בקטע שבהמשך יש מידע נוסף על סביבות. |
|
משתמש |
בתוך הארגון, שבו המשתמש שיוצר את החשבון מוגדר אוטומטית כאדמין, אפשר ליצור משתמשים נוספים. המשתמשים משתייכים לצוות ה-API של הארגון, שכולל אנשים כמו אדמינים, יוצרים של מוצרי API ושרתי API של API, משתמשים שעוקבים אחר ניתוח נתונים ונתונים סטטיסטיים אחרים ועוד. למשתמשים שונים יכולים להיות תפקידים שונים והרשאות גישה שונות. לדוגמה, אפשר להגדיר חלק מהמשתמשים כאדמינים ארגוניים וכאדמינים של תפעול עם הרשאות שמאפשרות לשנות את הארגון ואת הרכיבים שלו. אפשר להגדיר משתמשים אחרים עם הרשאות ליצור שרתי proxy של API ומוצרי API, אבל בלי ההרשאות לשינוי של משתמשים אחרים. המשתמשים יכולים להיות חברים במספר ארגונים. לדוגמה, החברה שלך יכולה להגדיר כמה ארגונים ב-Apigee Edge לתמיכה בקהילות מפתחים שונות. אבל באופן פנימי, אותם אנשים בונים את כל שרתי ה-API ומוצרי ה-API, ולכן הם חברים בכל הארגונים שלכם. אין צורך ליצור חשבון Apigee – כלומר, ליצור ארגון Apigee – כדי להיות משתמש. אדמין יכול להוסיף אתכם לארגון קיים. כל המשתמשים יכולים להתחבר ל-Apigee Edge כאן: https://enterprise.apigee.com. |
|
API מסוג proxy |
המשתמשים בארגון יוצרים שרת proxy אחד או יותר של API. שרת proxy ל-API מגדיר מיפוי של נקודת קצה (endpoint) של HTTP שזמינה באופן ציבורי לשירות לקצה העורפי. אפשר גם להגדיר שרתי proxy של API כך שיכללו אבטחה (כמו OAuth), יבצעו טרנספורמציה של הודעות (למשל XML ל-JSON), יגבילו את תעבורת הנתונים לשירותים לקצה העורפי ויבצעו פעולות חשובות אחרות לגבי הבקשה, התגובה ונכסי יתרונות מרכזיים של שירות. Edge אוספת נתונים לניתוח נתונים בשרתי proxy של API. |
|
מוצר API |
המשתמשים בארגון יוצרים מוצר API אחד או יותר, כאשר מוצר API הוא חבילה של שרתי proxy של API שמשולבים עם תוכנית שירות. באמצעות תוכנית השירות הזו אפשר להגדיר מגבלות גישה בשרתי proxy ל-API, לספק אבטחה, לאפשר מעקב וניתוח נתונים ולהציע תכונות נוספות. Edge אוספת נתונים לניתוח נתונים במוצרי API. |
|
המפַתח |
ארגון מכיל מפתח אחד או יותר שבונים את האפליקציות שצורכות את ממשקי ה-API (שמרכיבים מוצרים של API) שהוגדרו על ידי הארגון. מפתחים צורכים ממשקי API אבל לא יכולים ליצור ממשקי API או לבצע פעולות אחרות בארגון. המפתחים יכולים להיות פנימיים של החברה, שותפים או מפתחים חיצוניים שמשלמים על גישה לממשקי ה-API. המפתחים צריכים להיות רשומים בארגון כדי שיוכלו לרשום אפליקציה ולקבל מפתח API לצורך גישה לממשקי ה-API. כספקי API, אתם אלה שקובעים איך להוסיף, לעדכן או להסיר מפתחים בארגון. אפשר להוסיף אותם ידנית דרך ממשק המשתמש לניהול Edge, ליצור פורטל למפתחים ולרשום אותם דרך אתר, או להגדיר מנגנון רישום משלך באמצעות Edge Management API. למפתח לא נדרש חשבון ב-Edge, ורוב המפתחים לא צריכים לדעת דבר על Edge. אם למפתח יש חשבון ב-Edge, הוא בדרך כלל משתמש בארגון אחר או משתמש בשירותי Edge API. |
|
אפליקציה |
המפתחים יוצרים אפליקציית לקוח אחת או יותר שצורכות את ממשקי ה-API שלכם. מפתחים צריכים לרשום את האפליקציות שלהם בארגון. אפליקציה ב-Edge היא ייצוג של האפליקציה עצמה של המפתח, שמספקת למפתח מפתח API להעברה עם כל בקשה לממשקי ה-API שלך. מאחר שכל האפליקציות רשומות בארגון שלך, יש לך אפשרות להשתמש ב-Edge כדי לעקוב אחר נתוני ניתוח ולאסוף נתונים על האפליקציה ועל השימוש בממשקי ה-API שלך. |
|
מפתח API/אסימון OAuth |
בהתאם למנגנון ההרשאות שהגדרתם לממשקי ה-API, האפליקציה מעבירה מפתח API עם כל בקשה לממשקי ה-API שלכם. אם המפתח תקין, הבקשה מותרת. Edge תומך בסוגי אימות שונים, כמו מפתח API פשוט, OAuth דו-רגלי, OAuth תלת-רגלי ועוד. בתור ספקי API, אתם חייבים להגדיר דרך שבה המפתחים יכולים לרשום את האפליקציות שלהם. רישום האפליקציה של המפתח מאפשר להחזיר למפתח את המפתח שנדרש לגישה לממשקי ה-API. בזמן רישום האפליקציה, המפתח יכול לבחור אם לגשת למוצר API יחיד או למספר מוצרי API. באפליקציה עצמה של המפתח נעשה שימוש באותו מפתח כדי לגשת לכל מוצרי ה-API שמשויכים לאפליקציה (הייצוג הרשום של האפליקציה של המפתח ב-Edge). בכל שלב אפשר לבטל את המפתח כדי שלאפליקציה של המפתח לא תהיה יותר גישה לממשקי ה-API שלך (למרות שהייצוג הרשום של אפליקציית המפתח עדיין קיים בארגון שלך). אפשר גם להגדיר מגבלת זמן למפתח, כך שהמפתח יצטרך לרענן את המפתח אחרי פרק זמן ספציפי. |
מידע על סביבות
סביבה היא הקשר לביצוע בזמן ריצה לשרתי proxy של API בארגון. עליך לפרוס שרת proxy של API בסביבה כדי שתהיה אפשרות לגשת אליו. אפשר לפרוס שרת proxy ל-API בסביבה אחת או בכמה סביבות.
ארגון יכול להכיל מספר סביבות. לדוגמה, אפשר להגדיר בארגון את הסביבה dev,
test ו-prod.
הארגון מספק היקף לחלק מהיכולות של Apigee. לדוגמה, נתוני מפת מפתח-ערך (KVM) יכולים להיות זמינים ברמת הארגון, כלומר שרתי proxy של API שנפרסים בכל סביבה יקבלו את אותם נתונים מ-KVM. אפשר להגביל חלק מהיכולות, כמו שמירה במטמון, ברמת הארגון או לסביבה ספציפית בארגון. נתוני הניתוח של Apigee מופרדים לפי שילוב של ארגון וסביבה.
למטה מוצגות הישויות העיקריות שמנוהלות על ידך בארגון, כולל אלו שמוגדרות באופן גלובלי בארגון וישויות שמוגדרות באופן ספציפי לסביבה:
