אתם צופים במסמכי התיעוד של 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 Proxy מאמת את פרטי הכניסה לבקשה בשרתי ה-API Proxy שלכם על ידי הכללת מדיניות VerifyAPIKey או מדיניות OAuth/VerifyAccessToken בזרימה המתאימה. אם לא תכללו מדיניות לאכיפת אישורים ב-API Proxy, כל מי שיקרא ל-API יוכל להפעיל את ממשקי ה-API שלכם. מידע נוסף זמין במאמר בנושא אימות המדיניות בנושא מפתחות API.
כדי לאמת את פרטי הכניסה שמועברים בבקשה, Edge מבצע את השלבים הבאים:
- מקבלים את פרטי הכניסה שמועברים עם הבקשה. במקרה של אימות טוקן OAuth, Edge מאמת שהטוקן לא פג, ואז מחפש את מפתח הצרכן ששימש ליצירת הטוקן.
- אחזור רשימת מוצרי ה-API שאליהם משויך טוקן הצרכן.
- מוודאים ש-API Proxy הנוכחי כלול ב-API Product, ואם נתיב המשאב הנוכחי (נתיב ה-URL) מופעל ב-API Product.
- מוודאים שתוקף טוקן הצרכן לא פג או שהוא לא בוטל, בודקים שהאפליקציה לא בוטלה ושהמפַתח אפליקציות של האפליקציה פעיל.
אם כל הבדיקות שלמעלה עוברות בהצלחה, אימות פרטי הכניסה מצליח.
לסיכום, Edge יוצר באופן אוטומטי מפתחות צרכן, אבל בעלי תוכן דיגיטלי שמשתמשים ב-API צריכים לאכוף את בדיקת המפתחות בשרתי proxy ל-API באמצעות מדיניות מתאימה.
אישור אוטומטי לעומת אישור ידני
כברירת מחדל, כל הבקשות לקבלת מפתח לגישה למוצר API מאפליקציה מאושרות באופן אוטומטי. אפשרות אחרת היא להגדיר את מוצר ה-API כך שמפתחות יאושרו באופן ידני. במקרה כזה, תצטרכו לאשר בקשות למפתחות מכל אפליקציה שמוסיפה את מוצר ה-API. מידע נוסף זמין במאמר בנושא הרשמת אפליקציות וניהול מפתחות API.
מכסות
הקצאות יכולות להגן על שרתי הקצה העורפי שלכם מפני תנועה גבוהה, ולבדל את קו המוצרים שלכם. לדוגמה, אתם יכולים לצרף משאבים עם מכסה גבוהה כחלק ממוצר פרימיום, ולהשתמש באותה חבילה עם מכסה נמוכה יותר כחלק ממוצר בסיסי. הקצאת נפח אחסון יכולה לעזור להגן על השרתים שלכם מפני עומס יתר אם מוצר מסוים פופולרי ומקבל כמות גדולה של בקשות.
מידע על הגדרת מכסות זמין במאמר מדיניות מכסות. במאמר הקהילה הבא מוסבר איך משתמשים בהגדרות מכסה של מוצרים במדיניות מכסות: איך הגדרות המכסה במוצר API פועלות עם מדיניות מכסות בשרת proxy ל-API?
היקפי הרשאות OAuth
כדי להוסיף עוד שכבת אבטחה, אתם יכולים להגדיר היקפי הרשאות OAuth כרשימה מופרדת בפסיקים, שחייבים להיות באסימוני גישה שנשלחים דרך המוצר. כשיוצרים מוצר, צריך להכיר את כל ההיקפים שבהם הארגון משתמש. ההיקפים שמוסיפים למוצר צריכים להיות זהים להיקפים קיימים, אחרת המוצר לא יהיה מאובטח.
מידע נוסף על שימוש בהיקפי הרשאות עם כללי מדיניות של Edge OAuth זמין במאמר בנושא עבודה עם היקפי הרשאות של OAuth2.
רמות הגישה
כשמגדירים מוצר API, אפשר להגדיר את רמות הגישה הבאות.
| רמת גישה | תיאור |
|---|---|
| גלוי לכולם | מוצרי API שזמינים לכל המפתחים. אפשר להוסיף אותם לפורטלים משולבים למפתחים או לפורטלים שמבוססים על Drupal. |
| פרטי או פנימי בלבד | מוצרי API שמיועדים לשימוש פרטי או פנימי. הערה: אין הבדל פונקציונלי בין רמות הגישה 'פרטי' ו'לשימוש פנימי בלבד'. בוחרים את התווית שמתארת בצורה הטובה ביותר את קהל היעד של מוצר ה-API. בפורטל המשולב, אפשר להוסיף מוצרי API פרטיים או פנימיים בלבד ולהפוך אותם לזמינים למפתחי אפליקציות, לפי הצורך. בפורטלי מפתחים שמבוססים על Drupal, אפשר לנהל גישה למוצרי API פרטיים או פנימיים בלבד בפורטל המפתחים, כמו שמתואר בקטעים הבאים:
|