מבוא למוצרי API

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

בקטעים הבאים מוסבר על מוצרי API ועל מושגים קשורים כמו מכסות ומפתחות API.

מהו מוצר API?

כספקי API, אתם יוצרים מוצרי API כדי לאגד את ממשקי ה-API שלכם ולהפוך אותם לזמינים למפתחי אפליקציות לשימוש. אפשר לחשוב על מוצרי API כעל קו המוצרים שלכם.

באופן ספציפי, מוצר API כולל חבילה של פעולה אחת או יותר. פעולה מציינת שרת proxy ל-API ונתיבי משאבים שאפשר לגשת אליהם בשרת ה-proxy הזה. פעולה יכולה גם להגביל את הגישה לפי שיטות HTTP ולפי מכסת שימוש.

מוצרי API הם המנגנון המרכזי לבקרת גישה לממשקי ה-API שלכם. אם מגדירים מוצר API אחד או יותר באפליקציה למפתחים, אפשר להגביל את הגישה לשרתי proxy באמצעות מפתח API. ב-Apigee, מפתחות API מוקצים לא לממשקי API עצמם, אלא למוצרי API. במילים אחרות, מפתחות API מוקצים לחבילות של פעולות שמגדירות קו מוצרים או תוכנית שירות ספציפית.

תרחישים נפוצים לדוגמה

אתם יכולים ליצור כמה מוצרי API שמכילים פעולות שמתאימות לתרחישי שימוש ספציפיים. לדוגמה, אפשר ליצור מוצר API שכולל מספר פעולות שמכילות מיפוי משאבים, כדי לאפשר למפתחים לשלב בקלות מפות באפליקציות שלהם.

בנוסף, אפשר להשתמש במוצרי API כדי להגדיר רמות תמחור על סמך קריטריונים כמו:

מספר הבקשות:

  • ‫Premium: מספר בלתי מוגבל של בקשות ביום
  • בתוכנית הבסיסית: עד 1,000 בקשות ביום
  • בחינם: עד 100 בקשות ביום

או רמת הגישה:

  • ‫Premium: קריאה, כתיבה, עדכון ומחיקה
  • בסיסי: קריאה ועדכון
  • בחינם: קריאה בלבד

או כל שילוב של האפשרויות שלמעלה:

  • ‫Extra Premium: קריאה וכתיבה ללא הגבלה בכל יום
  • ‫Premium: קריאה וכתיבה של עד 1,000 בקשות ביום
  • בסיסי: גישת קריאה וכתיבה עד 100 פעמים ביום
  • בחינם: קריאה עד 1,000 פעמים ביום
  • בחינם: גישה לקריאה בלבד, מוגבלת ל-100 בקשות ביום

דרישות

מוצרי API שכלולים בתשלום לפי שימוש צריכים לכלול:

תפעול

פעולה היא קבוצה של מאפיינים שמגבילים את הגישה לאחד או יותר שרתי proxy של API על סמך קריטריונים כמו נתיב משאב, שיטת HTTP ומכסת שימוש. פעולה כוללת את המאפיינים הבאים:

מאפיין חובה? תיאור
API מסוג proxy חובה בכל קבוצת פעולות צריך לציין proxy ל-API. מותר להשתמש רק בשרת proxy אחד לכל קבוצת פעולות.
שירות מרחוק תלוי נדרש רק אם מתקינים את Apigee Adapter ל-Envoy ומתכננים להשתמש בו.
נתיב המשאב חובה בכל קבוצת פעולות צריך לציין נתיב משאב אחד או יותר. נתיבי משאבים בפעולה מגבילים את הגישה למשאבים ספציפיים ב-proxy ל-API. (נתיב משאב הוא החלק מכתובת ה-URL של בקשת proxy ל-API שמופיע אחרי נתיב הבסיס של ה-proxy).
שיטת HTTP אופציונלי אפשר גם להגביל את הגישה לשרת proxy לפי שיטת HTTP. לדוגמה, אם מציינים את ה-methods‏ GET ו-POST לקבוצת פעולות, רק בקשות HTTP‏ GET ו-POST יכולות לגשת ל-proxy עבור נתיב המשאב שצוין. אם לא מציינים שיטה, כל השיטות מותרות.
מכסה אופציונלי אפשר לציין מכסה לקבוצת הפעולות. המכסה שצוינה בקבוצת פעולות מקבלת עדיפות על פני מכסה ברמת מוצר ה-API, אם צוינה כזו.
מאפיינים מותאמים אישית אופציונלי מאפיינים מותאמים אישית שימושיים למדדים, למעקב או למקרים שבהם רוצים לשמור מידע נוסף על מוצר API שאפשר לגשת אליו או לאחזר אותו בהמשך. מאפיינים מותאמים אישית שמשויכים לפעולה קיימים בנוסף למאפיינים מותאמים אישית ברמת מוצר ה-API, ואפשר לגשת אליהם בזמן הריצה כמשתני זרימה עם הקידומת apiproduct.operation.attributes.

מפתחות API

כשרושמים אפליקציה של מפתח בארגון, צריך לשייך את האפליקציה למוצר API אחד לפחות. כתוצאה משיוך אפליקציה למוצר API אחד או יותר, מערכת Apigee מקצה לאפליקציה טוקן צרכן ייחודי. אפשר לקרוא גם את המאמר שליטה בגישה לממשקי ה-API באמצעות רישום אפליקציות.

טוקן הצרכן או אסימון הגישה משמשים כפרטי כניסה לבקשה. מפתח האפליקציה מטמיע את טוקן הצרכן באפליקציה, כך שכשהאפליקציה שולחת בקשה ל-API שמארח Apigee, האפליקציה מעבירה את טוקן הצרכן בבקשה באחת מהדרכים הבאות:

  • אם ה-API משתמש באימות של מפתח API, האפליקציה צריכה להעביר את טוקן הצרכן ישירות.
  • אם ה-API משתמש באימות של אסימון OAuth, האפליקציה צריכה להעביר אסימון שנוצר ממפתח הצרכן.

האכיפה של מפתח ה-API לא מתבצעת באופן אוטומטי. בין אם משתמשים בטוקן צרכן או באסימוני OAuth כפרטי כניסה לבקשה, proxy ל-API מאמת את פרטי הכניסה לבקשה ב-proxies ל-API על ידי הכללת מדיניות VerifyAPIKey או הגדרת מדיניות VerifyAccessToken (ראו מדיניות OAuthv2) בתהליך המתאים. אם לא כוללים מדיניות לאכיפת אישורים ב-API Proxy, כל מי שקורא ל-API יכול להפעיל את ממשקי ה-API.

כדי לאמת את פרטי הכניסה שמועברים בבקשה, Apigee מבצע את השלבים הבאים:

  1. מקבלים את פרטי הכניסה שמועברים עם הבקשה. במקרה של אימות אסימון OAuth, מערכת Apigee מאמתת שהתוקף של האסימון לא פג, ואז מחפשת את טוקן הצרכן ששימש ליצירת האסימון.
  2. אחזור רשימת מוצרי ה-API שאליהם משויך טוקן הצרכן.
  3. מוודאים שפרוקסי ה-API הנוכחי כלול במוצר ה-API, אם נתיב המשאב הנוכחי (נתיב ה-URL) מופעל במוצר ה-API, ואם הוא כלול במוצר, שהבקשה משתמשת בפועל HTTP שצוין.
  4. מוודאים שלא חרגתם מהמכסה, אם צוינה מכסה.
  5. מוודאים שתוקף טוקן הצרכן לא פג או שהוא לא בוטל, בודקים שהאפליקציה לא בוטלה ומבררים אם מפתח האפליקציה פעיל.

אם כל הבדיקות שלמעלה עוברות בהצלחה, אימות פרטי הכניסה מצליח.

לסיכום, Apigee יוצר באופן אוטומטי מפתחות צרכן, אבל בעלי תוכן דיגיטלי שמפרסמים API צריכים לאכוף בדיקת מפתחות ב-API proxies באמצעות שימוש במדיניות המתאימה.

אישור מפתח

כברירת מחדל, כל הבקשות לקבלת מפתח לגישה למוצר API מאפליקציה מאושרות באופן אוטומטי. אפשרות אחרת היא להגדיר את מוצר ה-API כך שיהיה צורך לאשר את המפתחות באופן ידני. ההגדרה הזו מתוארת במאמר בנושא ניהול מוצרי API. במקרה כזה, תצטרכו לאשר בקשות למפתחות מכל אפליקציה שמוסיפה את מוצר ה-API. מידע נוסף זמין במאמר בנושא שליטה בגישה לממשקי ה-API באמצעות רישום אפליקציות.

מכסות

הקצאות יכולות להגן על שרתי הקצה העורפי מפני שינויים גדולים בתנועת הגולשים, ולבדל את קו המוצרים שלכם. לדוגמה, אתם יכולים לכלול בחבילה משאבים עם מכסת שימוש גבוהה כמוצר פרימיום, ולהשתמש באותה חבילה עם מכסת שימוש נמוכה יותר כמוצר בסיסי. המיכסות יכולות לעזור לכם להגן על השרתים שלכם מפני עומס יתר אם מוצר מסוים פופולרי ומקבל כמות גדולה של בקשות בפרק זמן קצר.

אפשר לציין מכסה שחלה על כל שרתי ה-proxy ל-API שכלולים במוצר ה-API, או לציין מכסות ברמת הפעולה. מכסה שמוגדרת בפעולה מקבלת עדיפות על פני מכסה שמוגדרת ברמת מוצר ה-API.

הגדרת מכסות למוצר API לא גורמת לאכיפה אוטומטית של המכסות. זו פשוט מגבלת ברירת מחדל שאפשר להתייחס אליה במדיניות מכסות. אלה כמה יתרונות של הגדרת מכסה במוצר לצורך הפניה למדיניות בנושא מכסות:

  • משתמשים במדיניות מכסה כדי להחיל הגדרה אחידה על כל שרתי ה-proxy ל-API במוצר API.
  • אם משנים את הגדרות המכסה של מוצר ה-API בזמן הריצה, מדיניות המכסות מפנה אוטומטית להגדרות המכסה המעודכנות.

למידע נוסף, קראו את המאמרים הבאים:

היקפי ההרשאות של OAuth

אפשר להגדיר היקפי OAuth כרשימה מופרדת בפסיקים שצריכה להופיע באסימוני גישה שמשויכים למוצר. מידע נוסף על שימוש בהיקפי הרשאות עם מדיניות OAuth ב-Apigee זמין במאמר עבודה עם היקפי הרשאות של OAuth2.

רמות גישה

כשמגדירים מוצר API, אפשר להגדיר את רמות הגישה הבאות:

רמת גישה תיאור
Public מוצרי API שזמינים לכל המפתחים. אפשר להוסיף אותם לפורטלים משולבים למפתחים או לפורטלים למפתחים שמבוססים על Drupal.
Private או Internal only מוצרי API שמיועדים לשימוש פרטי או פנימי.

בפורטל המשולב, אפשר להוסיף מוצרי API‏ Private או Internal only ולהפוך אותם לזמינים למפתחי אפליקציות, לפי הצורך.

בפורטלי מפתחים שמבוססים על Drupal, אפשר לנהל את הגישה למוצרי API‏ Private או Internal only בפורטל המפתחים, כמו שמתואר בקטעים הבאים:

  • בפורטלי מפתחים של Drupal 10, אפשר להגדיר גישה למוצרי Private או Internal only API בפורטל המפתחים, כמו שמתואר במאמר הגדרת הרשאות גישה למוצרי API.

  • בפורטלי מפתחים של Drupal 7, אי אפשר להוסיף מוצרי API של Private או Internal only לפורטל המפתחים.

    כדי להפוך מוצרי API‏ Private או Internal only לזמינים למפתחי אפליקציות, צריך להוסיף אותם ידנית לאפליקציה רשומה מממשק המשתמש או ה-API של Apigee, כמו שמתואר במאמר שליטה בגישה ל-API באמצעות רישום אפליקציות.

    אחרי ההוספה, המפתח רואה בפורטל את מוצר ה-API שמשויך לאפליקציה, כמו שמתואר במאמר ניהול מוצרי API באפליקציה. אם מפתח האפליקציה משבית את הגישה למוצר API שהוא Private או Internal only, מוצר ה-API מוסר מהאפליקציה והאדמין של הפורטל צריך להוסיף אותו מחדש באופן ידני.