מוצג המסמך של 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 של management API מחזירה רשימה של כל שרתי ה-proxy ל-API בארגון:
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
סרטון: צפה בסרטון קצר כדי ללמוד כיצד ארגונים תומכים ארכיטקטורה מרובת דיירים לניהול API.
רכיבי הארגון
כשיוצרים חשבון Edge, דפדפן Edge יוצר עבורכם ארגון באופן אוטומטי. פעם אחת נוצרה, אפשר להוסיף משתמשים לארגון, ליצור שרתי proxy ל-API ומוצרי API, לרשום מפתחים ואפליקציות.
בתמונה הבאה מוצגים הרכיבים העיקריים במודל הארגוני של Edge. הזה מגדיר את הקשר בין ממשקי ה-API, מוצרי ה-API, האפליקציות ומפתחי האפליקציות שלכם קצה.
המודל הזה לא מציג את כל התכונות של Apigee Edge. אם אתם משתמשים במונטיזציה, המודל יכלול רכיבים נוספים. מידע נוסף זמין במאמר הבא: סקירה כללית בנושא מונטיזציה. צפייה ניהול חברות ומפתחים למידע על ניהול חברות ומפתחים באמצעות מונטיזציה.
שמות הארגונים
שם הארגון הוא:
- ארגון ההערכה:
username-eval - ארגון בתשלום: מוגדר על ידי המשתמש בזמן ההקצאה הראשונית
לאחר יצירת הארגון, לא ניתן לשנות את השם שלו.
שם הארגון הופך לחלק מכתובת ה-URL לשרתי ה-proxy ל-API ולחלק מכתובת ה-URL כאשר שליחת בקשה ל-Edge management API. לדוגמה, כתובת URL אופיינית שמשמשת לגישה ל-API ב-Proxy מופיע בצורה הבאה:
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 של הארגון שיכול לכלול אנשים כמו אדמינים, proxy ל-API ויוצרי מוצרי API, משתמשים שעוקבים אחר ניתוחים ונתונים סטטיסטיים אחרים ועוד. משתמשים שונים יכולים לקבל תפקידים שונים והרשאות גישה שונות. לדוגמה, הגדירו משתמשים מסוימים כאדמינים ארגוניים ומנהלי תפעול עם הרשאות כדי לשנות את הארגון ואת הרכיבים שלו. הגדרת משתמשים אחרים שיש להם הרשאות לבצע ליצור שרתי proxy ל-API ומוצרי API, אבל ללא הרשאות לשינוי הגדרות אחרות משתמשים. המשתמשים יכולים להיות חברים במספר ארגונים. לדוגמה, החברה שלכם עשויה להגדיר מספר ארגונים ב-Apigee Edge כדי לתמוך בקהילות מפתחים שונות. עם זאת, באופן פנימי, אותם אנשים בונים את כל מוצרי ה-proxy ל-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 management, יוצרים פורטל מפתחים כדי לרשום אותם או להגדיר מנגנון רישום משלך באמצעות ניהול Edge, 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 בסביבה לפני שאפשר יהיה לגשת אליה. אפשר לפרוס ממשק API שרת proxy לסביבה יחידה או למספר סביבות.
ארגון יכול להכיל כמה סביבות. לדוגמה, אפשר להגדיר dev,
test ו-prod בארגון.
הארגון מספק היקף ליכולות מסוימות של Apigee. לדוגמה, מיפוי של מפתח-ערך (KVM) יכולים להיות זמינים ברמת הארגון, כלומר ששרתי proxy ל-API פרוסים תקבל את אותם נתונים מ-KVM. אפשר להגביל חלק מהיכולות, כמו שמירה במטמון לארגון או לסביבה ספציפית בתוך הארגון. נתוני הניתוח של Apigee מחולקים למחיצות (partitioning) לפי שילוב של ארגון וסביבה.
למטה מוצגות הישויות העיקריות שמנוהלות על ידך בארגון, כולל אלו שהוגדרו בכל העולם בארגון, ואלה שמוגדרים באופן ספציפי לסביבה:
