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

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

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

איך קובעים את כתובת ה-URL של נקודת הקצה של שרת ה-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} הוא שם הסביבה של Edge. כברירת מחדל, כל הארגונים ב-Apigee שנוצרים בענן מקבלים שתי סביבות: test ו-prod. כשפורסים שרת proxy ל-API, אפשר לפרוס אותו באחת מהסביבות או בשתיהן.
• {base-path} ו-{resource-path} מוגדרים כשיוצרים את שרת ה-proxy ל-API.

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

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

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

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

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

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

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

• כתובת URL ישירה לשירות לקצה העורפי.
• הגדרה יחידה של TargetEndpoint.
• כמה TargetEndpoints שבהם שרת ה-API העביר את הבקשה לנקודת קצה יעד על סמך תנאי.
• נתיב או יעד Null, כלומר הבקשה לא מועברת ליעד. במקום זאת, כל עיבוד הבקשה ויצירת התגובה נעשים ב-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>

כל הבקשות לשרת ה-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

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

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

<RouteRule name="GoNowhere"/>

מידע נוסף

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