מסמך עזר בנושא תנאים

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תנאים מאפשרים לשרתי proxy של API להתנהג באופן דינמי בזמן הריצה. התנאים מגדירים פעולות על משתנים, שמוערכים על ידי צינור העיבוד של Apigee Edge. משפטי תנאי הם בוליאניים ותמיד שווים ל-true או ל-false.

סקירה כללית של התנאים

בקטע הזה מוסבר איך ואיפה להשתמש במשפטי תנאי ב-Edge. בנוסף, בקטעים הבאים מתואר התחביר:

• אופרטורים
• אופרנדים
• Literals

המבנה של משפטי תנאי

המבנה הבסיסי של משפט מותנה הוא:

<Condition>variable.name operator "value"</Condition>

לדוגמה:

<Condition>request.verb = "GET"</Condition>

אפשר לשלב תנאים עם AND כדי לאכוף יותר מתנאי אחד בכל פעם. לדוגמה, התנאים הבאים יחזירו את הערך true רק אם ה-URI של הבקשה תואם ל-/statuses וגם פועל ה-HTTP של הבקשה הוא GET:

<Condition>(proxy.pathsuffix MatchesPath "/statuses") and (request.verb = "GET")</Condition>

איפה אפשר להשתמש בהצהרות תנאי

אפשר להשתמש בתנאים כדי לשלוט בהתנהגות במקומות הבאים:

• הפעלת המדיניות
• ביצוע של תהליך
• בחירת מסלול של נקודת קצה ליעד

ביצוע המדיניות

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

בדוגמה הבאה, מתבצעת המרה מ-XML ל-JSON על סמך הכותרת Accept:

<Step>
  <Condition>request.header.accept = "application/json"</Condition>
  <Name>XMLToJSON</Name>
</Step>

ביצוע של תהליך

באמצעות משפטי תנאי, אפשר לשלוט בהרצה של זרימות בעלות שם ב-ProxyEndpoints וב-TargetEndpoints. חשוב לזכור שאפשר להפעיל זרימות מותנות רק אם הן קיבלו שם. הפעולות של Preflows ו-postflows (גם בקשות וגם תגובות) ב-ProxyEndpoints וב-TargetEndpoints מתבצעות בכל טרנזקציה, ולכן הן מספקות יכולות 'בטוחות' ללא תנאי.

לדוגמה, כדי להפעיל זרימת בקשה מותנית על סמך פועל ה-HTTP של הודעת הבקשה, וזרימת תגובה מותנית על סמך קוד סטטוס של HTTP (פוטנציאלי) שמייצג שגיאה:

<Flow name="GetRequests">
  <Condition>request.verb = "GET"</Condition>
  <Request>
    <Step>
      <Condition>request.path MatchesPath "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

בחירת מסלול של נקודת קצה ליעד

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

לדוגמה, כדי לנתב הודעות באופן מותנה לנקודות קצה ייעודיות על סמך Content-Type:

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.Content-Type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

מידע נוסף זמין במאמר משתני זרימה ותנאים.

ביטויי נתיב

ביטויים של נתיבים משמשים להתאמה של נתיבי URI, באמצעות '*' לייצוג של רכיב נתיב יחיד ו-'**' לייצוג של כמה רמות URI.

לדוגמה:

‫% נחשב לתו בריחה. התבנית %{user%} תואמת ל-{user} אבל לא ל-user.

משתנים

אפשר להשתמש גם במשתני זרימה מובנים וגם במשתנים מותאמים אישית במשפטי תנאי. מידע נוסף זמין בדפים הבאים:

• הפניה למשתני זרימה: רשימה מלאה של המשתנים המובְנים
• מדיניות ExtractVariables: הוראות להגדרת משתנים מותאמים אישית

אופרטורים

כשמשתמשים באופרטורים, חשוב לשים לב להגבלות הבאות:

• אי אפשר להשתמש באופרטורים כשמות של משתנים.
• צריך להוסיף רווח לפני ואחרי כל אופרטור.
• כדי לכלול אופרטור במשתנה, צריך להוסיף מרכאות בודדות לשם המשתנה. לדוגמה, 'request.header.help!me'.
• אין תמיכה באופרטורים אריתמטיים (+ * - / %).
• הקדימות של Java משמשת לאופרטורים.
• ‫Apigee Edge מסתמך על ביטויים רגולריים שמוטמעים ב-java.util.regex.

בטבלה הבאה מפורטים האופרטורים הנתמכים. אפשר להשתמש בסמל או במילה בביטויים:

אופרנדים

‫Apigee Edge מתאים אופרנדים לסוג נתונים משותף לפני השוואה ביניהם. לדוגמה, אם קוד הסטטוס של התגובה הוא 404, הביטוי response.status.code = "400" והביטוי response.status.code = 400 שווים.

עבור אופרנדים מספריים, סוג הנתונים מפורש כמספר שלם, אלא אם הערך מסתיים באופן הבא:

• ‫'f' או 'F' (מספרים עשרוניים, לדוגמה, 3.142f, ‏ 91.1F)
• ‫d או D (מספרים כפולים, לדוגמה, 3.142d, ‏ 100.123D)
• ‫l או L (long, לדוגמה, 12321421312L)

במקרים כאלה, המערכת מבצעת התאמות שמוצגות בטבלה הבאה (כאשר RHS מתייחס לצד ימין של המשוואה ו-LHS לצד שמאל):

אופרנדים מסוג Null

בטבלה הבאה מוצגות התוצאות של התנאים true או false כשערכים הם null בצד ימין (RHS) או בצד שמאל (LHS) של האופרנד שמוצג:

Literals

בנוסף למחרוזות ולערכים מספריים קבועים, אפשר להשתמש בערכים הקבועים הבאים במשפטי תנאי:

• null
• true
• false

לדוגמה:

• request.header.host is null
• flow.cachehit is true

דוגמאות

<RouteRule name="default">
     <Condition>request.header.content-type = "text/xml"</Condition>
     <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

<Step>
    <Condition>response.status.code = 503</Condition>
    <Name>MaintenancePolicy</Name>
</Step>

<Flow name="GetRequests">
    <Condition>response.verb="GET"</Condition>
    <Request>
        <Step>
            <Condition>request.path ~ "/statuses/**"</Condition>
            <Name>StatusesRequestPolicy</Name>
        </Step>
    </Request>
    <Response>
        <Step>
            <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
            <Name>MaintenancePolicy</Name>
        </Step>
    </Response>
</Flow>