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