אתם צופים במסמכי התיעוד של 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, אם אתם שייכים ליותר מארגון אחד, אתם יכולים לעבור לארגון אחר כמו שמתואר במאמר מעבר בין הארגונים שלכם.
- כשמבצעים קריאות ל-API לניהול בתור משתמש בתפקיד אדמין ארגוני, הארגון הוא חלק חובה בנתיב ברוב הקריאות. לדוגמה, בקשת cURL הבאה ל-Management API מחזירה רשימה של כל ה-API Proxy בארגון:
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, האפליקציות ומפתחי האפליקציות ב-Edge.
במודל הזה לא מוצגות כל התכונות של Apigee Edge. אם אתם מפעילים מונטיזציה, המודל יכלול רכיבים נוספים. מידע נוסף מופיע במאמר בנושא סקירה כללית על מונטיזציה. מידע על ניהול חברות ומפתחים עם מונטיזציה זמין במאמר בנושא ניהול חברות ומפתחים.
שמות הארגונים
שם הארגון הוא:
- ארגון ההערכה:
username-eval - ארגון בתשלום: מוגדר על ידי המשתמש בזמן ההקצאה הראשונית
אחרי שיוצרים ארגון, אי אפשר לשנות את השם שלו.
שם הארגון הופך לחלק מכתובת ה-URL של שרתי ה-API שלכם, וגם לחלק מכתובת ה-URL כשמבצעים בקשה ל-Edge Management API. לדוגמה, כתובת URL טיפוסית שמשמשת לגישה לשרת proxy של API היא מהצורה:
http://org-name-env.apigee.net/v1/weather/forecastrss
where:
- org-name הוא שם הארגון.
- env היא סביבת הפריסה של ה-proxy ל-API, שהיא test או prod.
לדוגמה:
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. |
|
proxy ל-API |
המשתמשים בארגון יוצרים פרוקסי של API אחד או יותר. proxy ל-API מגדיר מיפוי של נקודת קצה (endpoint) של HTTP שזמינה לציבור לשירות קצה עורפי. אפשר גם להגדיר שרתי proxy של API כך שיכללו אבטחה (כמו OAuth), יבצעו המרה של הודעות (כמו XML ל-JSON), יגבילו את התנועה לשירותי קצה עורפיים ויבצעו פעולות חשובות אחרות על הבקשה, על התגובה ועל קריאות לשירותים. Edge אוסף נתונים לצורך ניתוח של שרתי proxy של API. |
|
מוצר API |
המשתמשים בארגון יוצרים מוצר API אחד או יותר, כאשר מוצר API הוא חבילה של שרתי proxy ל-API בשילוב עם תוכנית שירות. תוכנית השירות הזו יכולה להגדיר מגבלות גישה לפרוקסי של API, לספק אבטחה, לאפשר מעקב וניתוח ולספק תכונות נוספות. Edge אוסף נתונים לצורך ניתוח של מוצרי API. |
|
מפתח |
ארגון מכיל מפתח אחד או יותר שיוצרים את האפליקציות שצורכות את ממשקי ה-API (שמורכבים ממוצרי API) שהוגדרו על ידי הארגון. מפתחים משתמשים בממשקי API, אבל לא יכולים ליצור ממשקי API או לבצע פעולות אחרות בארגון. המפתחים יכולים להיות עובדים בחברה שלכם, שותפים או מפתחים חיצוניים שמשלמים על גישה לממשקי ה-API שלכם. מפתחים צריכים להיות רשומים בארגון שלכם כדי שיוכלו לרשום אפליקציה ולקבל מפתח API כדי לגשת לממשקי ה-API שלכם. בתור ספקי API, אתם קובעים איך להוסיף, לעדכן או להסיר מפתחים בארגון שלכם. אפשר להוסיף אותם באופן ידני דרך ממשק המשתמש לניהול Edge, ליצור פורטל למפתחים כדי לרשום אותם דרך אתר, או להגדיר מנגנון רישום משלכם באמצעות Edge Management API. מפתחים לא צריכים חשבון ב-Edge, ורוב המפתחים לא צריכים לדעת שום דבר על Edge. אם למפתח יש חשבון ב-Edge, בדרך כלל זה חשבון משתמש בארגון אחר, או חשבון שמאפשר לו להשתמש בשירותי ה-API של Edge. |
|
אפליקציה |
מפתחים יוצרים אפליקציות לקוח אחת או יותר שצורכות את ממשקי ה-API שלכם. המפתחים צריכים לרשום את האפליקציות שלהם בארגון שלכם. אפליקציה ב-Edge היא ייצוג של אפליקציה בפועל של מפתח, שמספק למפתח מפתח API להעברה עם כל בקשה ל-APIs שלו. מכיוון שכל האפליקציות רשומות בארגון, אתם יכולים להשתמש ב-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 מחולקים למחיצות לפי שילוב של ארגון וסביבה.
בהמשך מוצגים הישויות העיקריות שמנהלים בארגון, כולל אלה שמוגדרות באופן גלובלי בארגון ואלה שמוגדרות באופן ספציפי לסביבה:
