הסבר על מסלולים

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

נתיב קובע את הנתיב של הבקשה מ-ProxyEndpoint אל TargetEndpoint. במסלול כלולה כתובת ה-URL שמשמשת לגישה ל-ProxyEndpoint של ה-API ואת כתובת ה-URL של הקצה העורפי השירות מוגדר על ידי TargetEndpoint.

זיהוי כתובת האתר של שרת ה-proxy של ה-API נקודת קצה

בתמונה הבאה מוצגת בקשה שמגיעה מאפליקציה ל-ProxyEndpoint. בקשה שתופנה לשירות לקצה העורפי:

אחרי שיוצרים שרת proxy ל-API ב-Edge, כתובת ה-URL שמוגדרת כברירת מחדל שהאפליקציה משתמשת בה כדי לגשת לשרת ה-proxy בצורה הבאה:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

איפה:

• {org-name} הוא שם הארגון. השם הזה נוצר כשיוצרים חשבון ב-Edge.
• {env-name} הוא שם סביבת הקצה. כברירת מחדל, כל ארגוני Apigee שנוצרים בענן מוקצה לשתי סביבות: 'test' ו-'prod'. במהלך פריסת שרת proxy ל-API, תוכלו לבחור לפרוס אותו באחת מהסביבות או בשתיהן.
• {base-path} ו-{base-path} מוגדרים כאשר יוצרים את ה-proxy ל-API.

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

http://myOrg-prod.apigee.net/v1/weather/forecastrss

אם בוחנים את ההגדרה של ProxyEndpoint לשרת ה-proxy ל-API בדוגמה שלמעלה, ניתן לראות האופן שבו כתובת ה-URL הזו מנתחת על ידי Edge:

1. החלק של הדומיין בכתובת ה-URL, http://myOrg-prod.apigee.net, תואם למארח וירטואלי ב-Edge. בהגדרה של ProxyEndpoint שלמעלה, ה-Proxy ל-API משתמש בתג <VirtualHost> כדי להפנות למארח וירטואלי בשם default. אפשר ליצור כמה משחקים וירטואליים מארחים שמוגדרים בסביבה שלכם.
   
   מארח וירטואלי מגדיר את הדומיינים והיציאות שבהם נחשף שרת proxy של API. מארח וירטואלי מגדיר גם אם תתבצע גישה לשרת ה-proxy של ה-API באמצעות פרוטוקול HTTP, או באמצעות שרת ה-proxy המוצפן בפרוטוקול HTTPS. למידע מפורט על מארחים וירטואליים, ראו מידע על מארחים וירטואליים (בטא).
2. החלק השני של כתובת ה-URL, /v1/weather, נקבע לפי הרכיב <BasePath> ברכיב נקודת קצה לשרת proxy. נתיב הבסיס חייב להיות ייחודי לשרת ה-proxy ל-API עבור הסביבה, כך לשרתי proxy ל-API אין אותו נתיב בסיס.
3. החלק השלישי של כתובת ה-URL, /forecastrss, הוא משאב שמוגדר על ידי שרת proxy ל-API עם הזרימה המותנית המתאימה שהוגדר על ידי התג <Flows>.

קביעת כתובת ה-URL של נקודת הקצה של היעד

התג <RouteRule> בקובץ ההגדרה של ProxyEndpoint קובעת את היעד של שרת ה-proxy ל-API, והיא מוערכת אחרי הכול כללי המדיניות בשדות PreFlow, Conditional Flows ו-PostFlow של בקשת ה-ProxyEndpoint הם עבר עיבוד.

נקודת קצה בשרת proxy יכולה להגדיר את היעד כך:

• כתובת URL ישירה לשירות לקצה העורפי.
• הגדרה יחידה של נקודת קצה (TargetEndpoint).
• נקודות TargetEnd מרובות שבהן שרת ה-proxy ל-API מאציל את הבקשה ליעד נקודת קצה (endpoint) לפי תנאי.
• נתיב או יעד ריקים, כלומר הבקשה לא מועברת ליעד. במקום זאת, כל עיבוד הבקשה ויצירת התגובה יתבצעו ב-Edge.

כתובת URL ישירה

נקודת ProxyEndpoint יכולה להפעיל שירות לקצה העורפי באופן ישיר, תוך עקיפה של כל נקודת קצה (TargetEndpoint) בעלת שם הגדרה אישית. לדוגמה, התג <RouteRule> הבא תמיד גורם ל-HTTP קריאה אל http://api.mycompany.com/myAPI:

<RouteRule name="default">
  <URL>http://api.mycompany.com/myAPI</URL> 
</RouteRule>

עם זאת, מכיוון שאין נקודת קצה (TargetEndpoint), אפשר להוסיף מדיניות רק לתהליכים שהוגדרו על ידי ProxyEndpoint.

יעד יחיד

בהגדרת יעד יחידה, ProxyEndpoint מפנה להגדרה אחת של נקודת קצה (TargetEndpoint) לפי שם, כפי שמוצג באיור שלמעלה:

<RouteRule name="default">
  <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

כל הבקשות לשרת ה-Proxy ל-API מופנות לאותה הגדרה של נקודת קצה (TargetEndpoint). התג <URL> בקטע נקודת הקצה (TargetEndpoint) קובעת את המיקום של השירות לקצה העורפי. כפי שמתואר למעלה, כתובת ה-URL היא http://weather.yahooapis.com.

יעדים מותנים

התג <RouteRule> מאפשר מפנים בקשה ליעד על סמך תנאי. אפשר להשתמש במשתני זרימה, פרמטרים, כותרות HTTP, תוכן הודעה או מידע הקשרי, כגון שעה ביום ולוקאל כדי לקבוע את נקודת הקצה כיעד. לדוגמה, אפשר לכלול אזור גיאוגרפי, כמו ארה"ב. ובבריטניה, בכתובת URL של בקשה. לאחר מכן אפשר לנתב בקשה לנקודת קצה (endpoint) של יעד על סמך אזור.

כלל הניתוב הבא מבצע הערכה של כותרת HTTP בבקשה. אם כותרת ה-HTTP ל-routeTo יש את הערך. TargetEndpoint1, ואז הבקשה מועברת לנקודת קצה (TargetEndpoint) בשם TargetEndpoint1. אם לא, הבקשה תועבר ל-TargetEndpoint2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

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

למידע נוסף, ניתן לעיין במסלולים מותנים. והתנאים וההגבלות.

נתיב ריק

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

בדוגמה הבאה מוגדר נתיב null:

<RouteRule name="GoNowhere"/>

מידע נוסף

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