כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
בקטעים הבאים מתוארים מוצרי API ומושגי מפתח קשורים.
מהו מוצר API?
בתור ספקי API, אתם יוצרים מוצרי API כדי לקבץ את ממשקי ה-API שלכם ולאפשר למפתחי אפליקציות להשתמש בהם לצורך צריכה. אפשר לחשוב על מוצרי API בתור קו המוצרים שלכם.
באופן ספציפי, מוצר API כולל את הרכיבים הבאים:
- אוסף של משאבי API (מזהי URI)
- תוכנית השירות
- מטא-נתונים ספציפיים לעסק לצורכי מעקב או ניתוח נתונים (אופציונלי)
משאבי ה-API שנכללים במוצר API יכולים להגיע מממשק API אחד או יותר, כך שניתן לשלב בין המשאבים וליצור קבוצות תכונות מיוחדות, כפי שמתואר באיור הבא.
אתם יכולים ליצור כמה מוצרים של API כדי לענות על תרחישים לדוגמה שעונים על צרכים ספציפיים. לדוגמה, אפשר ליצור מוצר של API שכולל כמה משאבי מיפוי כדי לאפשר למפתחים לשלב בקלות מפות באפליקציות שלהם. בנוסף, אפשר להגדיר מאפיינים שונים לכל מוצר API, למשל רמות תמחור שונות. לדוגמה, אפשר להציע את שילובי המוצרים הבאים דרך ממשק ה-API:
- מוצר API עם מגבלת גישה נמוכה, כמו 1,000 בקשות ביום, במחיר מוזל. מוצר API שני שמספק גישה לאותם המשאבים, אבל עם מגבלת גישה גבוהה יותר ומחיר גבוה יותר.
- מוצר API בחינם שמציע גישת קריאה בלבד למשאבים. מוצר API שני שמספק גישת קריאה/כתיבה לאותם משאבים תמורת חיוב קטן.
בנוסף, ניתן לשלוט בגישה למשאבי ה-API במוצר API מסוים. לדוגמה, אפשר לקבץ משאבים שמפתחים פנימיים יכולים לגשת אליהם בלבד, או רק לקוחות משלמים.
מוצרי API הם המנגנון המרכזי להרשאה ולבקרת גישה לממשקי ה-API. ב-Apigee, ההקצאה של מפתחות API מתבצעת, לא עבור ממשקי ה-API עצמם, אלא עבור מוצרי API. כלומר, מפתחות ה-API מוקצים לחבילות משאבים שמצורפת אליהן תוכנית שירות.
מפתחי אפליקציות ניגשים למוצרי ה-API על ידי רישום האפליקציות שלהם, כפי שמתואר ב'רישום אפליקציות'. כשאפליקציה מנסה לגשת למוצר של API, ההרשאה נאכפת על ידי Apigee בזמן הריצה כדי לוודא את הפרטים הבאים:
- האפליקציה ששלחה את הבקשה מורשית לגשת למשאב מסוים של ממשק API.
- האפליקציה שביקשה לא חרגה מהמכסה המותרת.
- אם הוגדר, היקפי ההרשאות של OAuth שמוגדרים במוצר ה-API תואמים לאלה שמשויכים לאסימון הגישה שהאפליקציה מציגה.
להבין את המושגים המרכזיים
לפני שיוצרים מוצרי API, כדאי לעיין במושגי המפתח הבאים.
מפתחות API
כשרושמים אפליקציה של מפתח בארגון, האפליקציה צריכה להיות משויכת למוצר API אחד לפחות. בעקבות התאמה בין אפליקציה לבין מוצר API אחד או יותר, Edge מקצה לאפליקציה מפתח צרכן ייחודי.
מפתח הצרכן או אסימון הגישה משמשים כפרטי כניסה לבקשה. מפתח האפליקציה מטמיע את מפתח הצרכן באפליקציה, כך שכאשר האפליקציה שולחת בקשה ל-API שמתארח ב-Edge, האפליקציה מעבירה את מפתח הצרכן בבקשה באחת מהדרכים הבאות:
- אם ה-API משתמש באימות של מפתח API, האפליקציה חייבת להעביר את מפתח הצרכן ישירות.
- כש-API משתמש באימות באמצעות אסימון OAuth, על האפליקציה להעביר אסימון שהופק ממפתח הצרכן.
האכיפה של מפתח API לא מתבצעת באופן אוטומטי. גם אם אתם משתמשים במפתח הצרכן או באסימוני OAuth כפרטי כניסה של בקשה, שרת ה-API של שרת ה-API מאמת את פרטי הכניסה של הבקשה בשרתי ה-proxy של ה-API. לשם כך, הוא כולל מדיניות OAuthAPIKey או מדיניות OAuth/VerifyAccessToken, בתהליך המתאים. אם לא כוללים מדיניות לאכיפת פרטי כניסה בשרת ה-API של ה-API, כל מבצע קריאה יכול להפעיל את ממשקי ה-API. מידע נוסף זמין במאמר המדיניות בנושא אימות מפתח API.
כדי לאמת את פרטי הכניסה שהועברו בבקשה, Edge מבצע את השלבים הבאים:
- קבלת פרטי הכניסה שמועברים עם הבקשה. במקרה של אימות אסימון OAuth, Edge מוודא שתוקף האסימון לא פג, ולאחר מכן מחפש את מפתח הצרכן ששימש ליצירת האסימון.
- מאחזרים את רשימת מוצרי ה-API שאליהם מפתח הצרכן משויך.
- צריך לוודא ששרת ה-API הנוכחי נכלל במוצר ה-API, ואם נתיב המשאב הנוכחי (נתיב כתובת ה-URL) מופעל במוצר ה-API.
- צריך לוודא שמפתח הצרכן לא פג תוקף או מבוטל, לבדוק שהאפליקציה לא בוטלה ולבדוק שמפתח האפליקציה פעיל.
אם כל הבדיקות האלה עוברות בהצלחה, תהליך האימות של פרטי הכניסה מסתיים בהצלחה.
בשורה התחתונה, Edge יוצר מפתחות צרכנים באופן אוטומטי, אבל בעלי אפליקציות ב-API צריכים לאכוף בדיקת מפתחות בשרתי proxy של API באמצעות המדיניות המתאימה.
אישור אוטומטי לעומת אישור ידני
כברירת מחדל, כל הבקשות לקבלת מפתח כדי לגשת למוצר API מהאפליקציה מאושרות באופן אוטומטי. לחלופין, אפשר להגדיר את מוצר ה-API לאישור מפתחות באופן ידני. במקרה כזה, יהיה עליך לאשר בקשות חשובות מכל אפליקציה שמוסיפה את מוצר ה-API. מידע נוסף זמין במאמר רישום אפליקציות וניהול של מפתחות API.
מכסות
מכסות עוזרות להגן על השרתים לקצה העורפי מפני נפח תנועה גבוה, וכך מבדלות את קו המוצרים שלכם. לדוגמה: יכול להיות שתרצו לקבץ משאבים עם מכסה גבוהה כמוצר פרימיום, ולהשתמש באותה חבילה עם מכסה נמוכה יותר כמו מוצר בסיסי. מכסה תעזור לך להגן על השרתים שלך מפני עומס יתר אם מוצר מסוים פופולרי ומקבל כמות גדולה של בקשות.
במדיניות בנושא מכסות מוסבר איך מגדירים מכסות. למידע נוסף על השימוש בהגדרות מכסות של מוצרים במדיניות המכסות, כדאי לעיין במאמר הקהילה הבא: איך הגדרות המכסה במוצר API פועלות עם מדיניות המכסה בשרת proxy ל-API?.
היקפי הרשאות של OAuth
כדי לשפר את האבטחה, ניתן להגדיר כל היקפי הרשאות של OAuth כרשימה מופרדת בפסיקים, שחייבים להיכלל באסימוני הגישה שנשלחים דרך המוצר. כשיוצרים מוצר, צריך להיות מודעים לכל ההיקפים שבהם הארגון שלכם משתמש. ההיקפים שמוסיפים למוצר חייבים להתאים להיקפי ההרשאות הקיימים, אחרת המוצר לא יהיה מאובטח.
מידע נוסף על השימוש בהיקפים עם מדיניות OAuth של Edge זמין במאמר עבודה עם היקפי OAuth2.
רמות הגישה
כשמגדירים מוצר API, אפשר להגדיר את רמות הגישה הבאות.
| רמת גישה | תיאור |
|---|---|
| גלוי לכולם | מוצרי API שזמינים לכל המפתחים. אפשר להוסיף אותן לפורטלים למפתחים משולבים או לפורטלים שמבוססים על Drupal. |
| פרטי או פנימי בלבד | מוצרי API שמיועדים לשימוש פרטי או פנימי. הערה: אין הבדל באופן פונקציונלי בין רמות הגישה 'פרטית' ו'פנימית בלבד'. יש לבחור את התווית שמתארת בצורה הטובה ביותר את קהל היעד של מוצר ה-API. בפורטל המשולב, אפשר להוסיף מוצרי API פרטיים או פנימיים בלבד, שיהיו זמינים למפתחי אפליקציות לפי הצורך. בפורטלים למפתחים המבוססים על Drupal, אפשר לנהל את הגישה למוצרי API פרטיים או פנימיים בלבד בפורטל למפתחים, כפי שמתואר בקטעים הבאים:
|