本頁面由 Cloud Translation API 翻譯而成。

含有流程變數的條件

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。資訊

條件陳述式是所有程式設計語言的通用控制結構，如程式設計語言，API Proxy 設定支援流程的條件陳述式政策、步驟和 RouteRules。透過定義條件陳述式，您可以定義動態行為。此動態行為可讓您執行某些操作，例如將 XML 轉換為 JSON 或是根據請求的內容類型或 HTTP 動詞，轉送到後端網址撰寫新的電子郵件訊息

本主題將說明如何使用條件來動態套用 API 管理功能：不必編寫任何程式碼

影片

如要進一步瞭解流程變數和條件，請觀看以下影片：

設定條件陳述式

使用條件的組合，即可在 API Proxy 中實作條件行為和變數條件陳述式是使用 Condition 元素建立。下列為空白條件：

<Condition></Condition>

如要建立條件陳述式，請新增條件運算子和變數，用於建立以下結構：

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

支援的條件運算子包括 = (等於)、!= (不等於)、和 > (大於)。為了方便閱讀，您也可以將條件式寫成文字：equals、notequals、greaterthan。

處理 URI 路徑時，您可以使用 ~/ 或 MatchesPath。你可以也會比對 JavaRegex 規則運算式與 ~~ 運算子。

條件是用來定義 API Proxy 對後端 API 資源的條件式流程，「建立後端 API 資源的條件式流程」。適用對象如需條件式的完整清單，請參閱條件參考資料。

變數

條件會評估變數的值來實際運作。變數是指 API Proxy 所執行 HTTP 交易的屬性，或是 API Proxy 的屬性資源本身當 API Proxy 收到來自應用程式的要求時，Apigee Edge 會填入與系統時間、應用程式網路等相關變數清單資訊、訊息的 HTTP 標頭、API Proxy 設定、政策執行等。這會建立豐富的背景資訊，可用來設定條件陳述式。

變數一律使用點號標記法。舉例來說，要求訊息的 HTTP 標頭為可做為 request.header.{header_name} 變數使用若要評估內容類型標頭，就可以使用 request.header.Content-type 變數。適用對象範例 request.header.Content-type = "application/json" 表示內容要求類型應為 JSON

假設您必須建立條件陳述式，使政策要求訊息為 GET 時才會強制執行。建立評估 HTTP 動詞的條件請在下方建立條件陳述式。這個條件中的變數是 request.verb。變數的值為 GET。運算子是 =。

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

您還可以使用：

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

Edge 會使用這類陳述式來評估條件。上述範例評估為 true，與要求相關聯的 HTTP 動詞為 GET。如果與要求相關聯的 HTTP 動詞為 POST，則該陳述式會傳回 false。

注意：Edge 會自動儲存所有 HTTP 標頭和查詢參數視為變數，可透過 request.header. 和 request.queryparam. 變數前置字元。

如要啟用動態行為，您可以將「條件」附加至流程、步驟和 RouteRules，

將條件附加至流程時，就會建立「條件式流程」。條件式流程只有在條件評估為 true 時才會執行。您可以視需要附加多個政策定義條件式 Flow條件式流程可讓您建立高度特殊的處理規則來傳回符合特定條件的要求或回應訊息

例如，若要建立僅在要求動詞為 GET 時執行的流程：

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
</Flows>

如何為 GET 和 POST 分別建立流程：

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
  <Flow name="ExecuteForPOSTs">
  <Condition>request.verb="POST"</Condition>
  </Flow>
</Flows>

如以下範例所示，您可以將條件套用至「政策步驟」本身。下列條件會導致只有在要求訊息為 POST。

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

定義這類條件流程後，您可為其附加政策，以啟用 API 透過 Proxy 對 GET 要求強制執行一組政策，以及對 POST 強制執行另一組政策要求。

如需完整的參考資訊，請參閱下列資源：

範例 1

以下範例顯示名為 Convert-for-devices 的單一條件式流程。列在 Proxy 端點回應流程中將條件新增為實體符合條件的內容在此範例中，條件是資料流的元件。因此，只要陳述式評估為 true，就會執行流程。

<Flows>
  <Flow name="Convert-for-devices">
  <Condition>(request.header.User-Agent = "Mozilla")</Condition>
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

對於從應用程式收到的每個要求，Edge 會儲存以下形式的所有 HTTP 標頭值：變數。如果要求包含名為 User-Agent 的 HTTP 標頭，該標頭並其值會儲存為 request.header.User-Agent 變數。

在上述 ProxyEndpoint 設定的情況下，Edge 會檢查 request.header.User-Agent 變數，查看條件是否得出 true。

如果條件確實為 True，就會是變數的值 request.header.User-Agent 等於 Mozilla，接著條件式流程，並強制執行名為 ConvertToJSON 的 XMLtoJSON 政策。如果不是，資料流，而且 XML 回應會傳回未經修改的 (採用 XML 格式) 給應用程式。

範例 2

讓我們使用您所需的特定範例，將回應訊息從 XML 轉換成 JSON—但僅適用於行動裝置。首先，請建立政策來從 Weather API 轉換為 JSON 的 XML 格式回應：

<XMLToJSON name="ConvertToJSON">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

上述政策設定會指示 API Proxy 接收回應訊息，並執行使用預設設定從 XML 轉換為 JSON，然後將結果寫入新的回應撰寫新的電子郵件訊息(如要將 request 訊息從 XML 轉換為 JSON，您只需將將這些數值設為 request)。

您想將回應從 XML 轉換為 JSON，因此您需要設定條件式以便執行轉換例如，將所有回應從 XML 轉換成 JSON 再傳回用戶端應用程式，請設定下列 ProxyEndpoint 回應流程。

<Flows>
  <Flow name="Convert-for-devices">
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

使用標準要求叫用 API 時，回應會採用 JSON 格式。

然而，您的目標是在請求用戶端時，只將「天氣」報表轉換為 JSON 屬於行動裝置。如要啟用這類動態行為，您必須加入條件陳述式流程

測試條件式流程

在這個要求範例中，HTTP User-Agent 標頭設為 Mozilla，讓條件陳述式評估 True 和條件式要執行的流程 Convert-for-devices。

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

或者在可使用 Python 的情況下美化列印：

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282 | python -mjson.tool

回應範例：

. . .

"yweather_forecast": [
         {
              "code": "11",
              "date": "12 Dec 2012",
              "day": "Wed",
              "high": "55",
              "low": "36",
              "text": "Showers"
          },
          {
              "code": "32",
              "date": "13 Dec 2012",
              "day": "Thu",
              "high": "56",
              "low": "38",
              "text": "Sunny"
          }
      ]
  }

. . .

提交的要求不含 User-Agent 標頭，或要求的值與 Mozilla，會產生 XML 格式的回應。

$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

系統會傳回未修改的 XML 回應。

回應範例：

<yweather:forecast day="Wed" date="12 Dec 2012" low="36" high="55" text="Showers" code="11" /> <yweather:forecast day="Thu" date="13 Dec 2012" low="38" high="56" text="Sunny" code="32" />

模式比對

本節說明如何在 Apigee 流程中將模式比對與條件搭配使用。

其他資訊

運算子

本節說明如何在條件式中使用下列模式比對運算子陳述式：

比對運算子：簡單的模式比對
JavaRegex 運算子：更精細的比對功能
MatchPath 運算子：路徑片段比對

相符

現在來看看「相符項目」或「~」條件運算子這兩個運算子相同 -- 英文版的「符合項目」是更容易閱讀的選項。

摘要：「相符影片」運算子有兩種可能必須符合字串常值，或是比對萬用字元「*」。與預期的情況一樣，萬用字元會比對零或多個字元。接下來是運作方式範例

以下 XML 顯示了步驟條件。這個觸發條件會在條件符合時執行 SomePolicy 政策會傳回 true。在本範例中，我們測試 proxy.pathsuffix 變數，內建變數，可儲存要求的路徑後置字串。但請注意任何包含字串的流程變數值。因此，在這個例子中傳入要求為 /animals，要求為 /animals/cat，則路徑後置字串是常值字串「/cat」。

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix Matches "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

問題：哪些 Proxy 路徑後置字串會導致 SomePolicy 執行？還有只有一個可能性

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？是，因為 Proxy 路徑後置字串與「/cat」相符當然，如果後置字串是 /bat、/dog 或「/」或其他任何問題

現在，請思考這個條件陳述式使用萬用字元「*」：

<Condition>(proxy.pathsuffix Matches "/*at")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？是，因為萬用字元比對任何字元，且 "/cat 吋即為比對符合的結果。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/bat

這項政策是否會執行？是，因為萬用字元符合任何字元 "/bat" 即為比對符合的結果。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/owl

這項政策是否會執行？當然不會，雖然萬用字元與「o」相符，字母「wl」就不符合條件

現在，請將萬用字元移至後置字串的結尾：

<Condition>(proxy.pathsuffix Matches "/cat*")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？是，因為萬用字元可以比對零個或多個任何字元。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/bat

這項政策是否會執行？不，「/bat」不符合條件。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat123

這項政策是否會執行？是，萬用字元會比對零個或多個任何字元，因此「123」就會產生相符項目

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat/bird/mouse

這項政策是否會執行？是，因為萬用字元可以比對零個或多個任何字元，所以「/bird/mouse」就會產生相符項目請留意這類運算式如何幫助你就會發生問題，因為該字元會比對常值字元後的所有內容！

問題：比對運算子是否區分大小寫？

會。假設您有如下的條件：

<Condition>(proxy.pathsuffix Matches "/*At")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？否，萬用字元會比對任何字母 (不論大小寫)，但小寫「a」不符合「A」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/bAt

這項政策是否會執行？是，案件相符。

問題：如何使用比對運算子逸出字元？

使用百分比為「%」字元才能逸出保留字元。例如：

<Condition>(proxy.pathsuffix Matches "/c%*at")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？否，「match」運算子在尋找常值字串「c*at」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/c*at

問題：政策是否適用？

是，雖然與此路徑有點不尋常，但與此路徑相符。

JavaRegex

如您所見運算子適用於簡單的情況但您可以使用另一個運算子，「JavaRegex」或「~~」運算子。這兩個運算子是相同的運算子，但 JavaRegex 與更容易閱讀叫做 JavaRegex 模式比對，Edge 會採用與 java.util.regex 中類別相同的規則套件。JavaRegex 運算子的運作方式與會比對運算子，因此請不要將兩者混淆！

注意：如果你習慣在 Perl 指令碼中執行規則運算式，請務必請注意，Edge 中的 JavaRegex 運算子會測試「整個」主體字串。適用對象舉例來說，如果主題是「abc」規則運算式是「[a-z]」，「[a-z]」表示不相符完全符合 ONE 個字母字元。運算式「[a-z]+」就像「[a-z]{3}」一樣。這種比對方法與 Perl 或 grep 或 Apache 的 mod_rewrite。JavaRegex 使用 java.util.regex.Pattern.matches(str)，定義會在整個字串 (str) 與模式相符時傳回正數。在 Perl 或 mod_rewrite 會套用至「any」字串部分。如果模式傳回 true 就會產生相同的結果請參閱範例：使用 JavaRegex。

摘要：「JavaRegex」運算子可讓您在條件陳述式。

下列程式碼說明步驟條件。如果條件符合，就會執行 somePolicy 政策會傳回 true。在本範例中，我們測試內建 proxy.pathsuffix 變數變數，用於儲存要求的路徑後置字串。如果傳入要求為 /animals，要求為 /animals/cat，則路徑後置字串是常值字串「/cat」。

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix JavaRegex "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

敬上

請務必記得，proxy.pathsuffix 變數是永遠以斜線 (「/」) 字元開頭，例如 /cat。因此，如果比對到「/c*t」，則代表要比對整個字串，包括「/」。「/」並未使用正常規則運算式接續。如要比對其他類型的變數，例如 request.querystring 一個「/」不必加入 (除非查詢參數的開頭是「/」)。

問題：哪些 Proxy 路徑後置字串會導致 SomePolicy 執行？就像這樣在這個例子中，系統只能使用「相符」運算子。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？是，因為 Proxy 路徑後置字串與「/cat」相符當然，如果後置字串是 /bat、/dog 或任何項目，則不會執行其他種類的廣告。

現在，讓我們使用「*」來建立規則運算式量詞這個量詞會與零或代表開頭的字元

<Condition>(proxy.pathsuffix JavaRegex "/c*t")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？不！"*"量詞會比對 0 個以上的前字元，也就是「c」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/ccccct

這項政策是否會執行？是，因為萬用字元與上述零個或多個前置字元相符字元。

接著，我們會使用「?」量詞，會比對前述字元一次，或不比對。

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？會。「?」量詞符合 0 或 1 次 上一個字元，也就是「a」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/ct

這項政策是否會執行？會。「?」量詞符合一 或不包含前接字元。在本例中，使用者不會有「a」字元，因此條件得出的值。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/caat

這項政策是否會執行？否，「?」量詞會比對上述其中「一個」字元，也就是「a」。

接著，我們會使用「[abc]」或「分組」規則運算式其符合字元「a」或「b」或「c」。

<Condition>(proxy.pathsuffix JavaRegex "/[cbr]at")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？會。這裡使用規則運算式「[cbr]」運算式會比對「c」、「b」、「OR」或「r」。這些呼叫也相符：

GET http://artomatic-test.apigee.net/matchtest/bat

GET http://artomatic-test.apigee.net/matchtest/rat

不過，這不是比對結果：

GET http://artomatic-test.apigee.net/matchtest/mat

問題：JavaRegex 運算子是否區分大小寫？

會。假設您有如下的條件：

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat

這項政策是否會執行？是，規則運算式會比對零或前一個字元，「a」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cAt

問題：這項政策是否適用？

不，因為首字母「A」與小寫「a」不符。

MatchesPath

指定 MatchesPath 運算子時，也可以像「~/」一樣。這看起來有點像 Matches (~) 和 JavaRegex (~~) 運算子。但 MatchPath 卻截然不同

但請記住，這個運算子會將路徑視為一系列的部分。因此，如果路徑為：/animals/cats/wild，您可以將路徑想成由各個部分組成的「/animals」、「/cats」和「/wild」。

MatchesPath 運算子可讓您使用兩種萬用字元標記法：一個星號 (*) 和雙星號 (**)，單一星號符合一個路徑元素。雙星號比對一或多個路徑元素

讓我們來看看下面這個例子。在本範例中，我們測試 proxy.pathsuffix 變數。內建變數，可儲存要求的路徑後置字串。但請注意測試任何包含字串的流程變數值。

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

問題：哪些 Proxy 路徑後置字串會導致 SomePolicy 執行？

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals

問題：這項政策是否適用？

否，因為條件在「/animals」，由「/*」指定。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/

這項政策是否會執行？是，路徑確實包含另一個 path 元素 (在「/animals/」)，但最近沒有內容。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/cats

這項政策是否會執行？是，因為路徑明確含有元素 (「/cats」) (出現在「/animals」之後)

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

問題：這項政策是否適用？

否，因為單一星號只能比對一個路徑元素，「/animals」之後，這個 API 有多個元素。

現在我們使用雙星號：

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

問題：哪些 Proxy 路徑後置字串會導致 SomePolicy 執行？

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals

這項政策是否會執行？否，因為條件至少需要一個下列路徑元素由「/**」指定。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/

這項政策是否會執行？

是，路徑確實包含另一個 path 元素 (在「/animals/」)，但最近沒有內容。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/cats

這項政策是否會執行？

是，因為路徑中至少有一個元素在「/animals」

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

這項政策是否會執行？

是，因為路徑在「/animals」

混合星號

您可以合併使用一個 (*) 和雙 (**) 星號，讓路徑比對。

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*/wild/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

API 呼叫：

這些 API 呼叫都會產生相符項目：

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild/

和

GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian

和

GET http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches

API 資源

符合 REST 樣式的服務是 API 資源集合。API 資源是 URI 路徑片段，用於識別開發人員可透過呼叫您的 API 存取的部分實體。例如：如果您的服務提供天氣報告和天氣預報，您的後端服務可能會定義兩項 API 資源：

http://mygreatweatherforecast.com/reports
http://mygreatweatherforecast.com/forecasts

其他資訊

建立 API Proxy (如建構第一個 API Proxy 一節) 時，您至少需要建立對應至後端服務的別名基本網址例如：

後端基本網址	新增/對等 API Proxy 網址
http://mygreatweatherforecast.com	http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

此時，您可以使用任一基本網址向後端發出 API 呼叫。但當您使用 API Proxy 網址，開始採取行動的樂趣了。

除了使用 API Proxy 時，Edge 會開始收集的 API 數據分析，也能定義與後端資源相對應的條件式流程本質上：「如果 GET 呼叫傳入 /reports 資源，Edge 應該採取什麼行動。」

下圖顯示兩個最終存取同一個後端一個是未經 Proxy 處理的資源網址，另一個則是 Edge API Proxy，將條件式流程傳送至相同後端資源我們會詳細說明條件式流程。

API Proxy 如何對應至特定後端資源

使用對應至後端服務基準網址的 API Proxy 網址 (建立 Proxy)，您可以將條件式流程新增至特定資源，例如 /reports 和前文提到的 /forecasts 項資源

假設您想要讓邊緣「做些什麼」自動回應 /reports 或 /forecasts 資源。此時，您不會告訴 Edge 該怎麼做，只應監聽對這些資源的呼叫。您做得到當中包含條件您可以在 Edge API Proxy 中為《/reports》和《/forecasts》。以下 API 說明概念 Proxy XML 會顯示這些條件的樣子

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
    </Flow>
    <Flow name="forecasts">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/forecasts") and (request.verb = "GET")</Condition>
    </Flow>
</Flows>

這些條件會顯示：「當 GET 要求隨附於 /reports，且網址中的 /forecasts，Edge 會執行您 (API 開發人員) 要求的任何操作，附加在各個流程中的政策

現在的例子是讓 Edge 在符合條件時處置方式。在下列 API 中將 GET 要求傳送至 Proxy XML 時 https://yourorg-test.apigee.net/mygreatweatherforecast/reports，邊緣執行「XML-to-JSON-1」回應政策中的政策。

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response>
            <Step>
                <Name>XML-to-JSON-1</Name>
            </Step>
        </Response>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
</Flow>

除了這些選用的條件式流程之外，每個 API Proxy 也含有兩個預設值資料流：在條件式流程之前執行的 <PreFlow>，以及 <PostFlow> 會在條件流程後執行。這些對於當 API Proxy 有任何呼叫時，才會執行政策。舉例來說每當您呼叫後端資源時，每次呼叫都會驗證應用程式的 API 金鑰可能在 <PreFlow> 中加入 Verify API 金鑰政策。如要進一步瞭解流程，請參閱設定流程。

建立後端資源的條件式流程

您完全不需要在 API Proxy 中定義到後端資源的條件式流程。但這些條件式流程可讓您套用精細的管理機制和監控功能

你將可以：

根據 API 模型語意的方式應用管理
將政策和指令碼行為套用至個別資源路徑 (URI)
收集 Analytics 服務的精細指標

舉例來說，假設您需要將不同類型的邏輯套用至後端 /developers 至 /apps 資源。

為此，請在 API Proxy 中新增兩個條件式流程：/developers 和 /apps。

在 API Proxy 編輯器的「Navigator」窗格中的「Development」檢視畫面，按一下 + 圖示位於 Proxy 端點的預設旁邊

在「New Conditional Flow」中視窗中，請輸入下列重要設定：

流程名稱：開發人員
條件類型：路徑
路徑：/developers

若有呼叫傳送至 Proxy，就會觸發條件並觸發政策在 URI 結尾加上 /developers

接著為 /apps 新增條件式流程，並假設您想在要求中的 URI 和 POST 動詞這項設定需要設定包括：

Flow Name：應用程式
條件類型：路徑和動詞
路徑：/apps
動詞：POST

若有呼叫傳送至 Proxy，就會觸發條件並觸發政策在 URI 結尾加上 /apps 和 POST 動詞

「Navigator」窗格會顯示「應用程式」和 開發人員。

選取其中一個流程，即可在 API Proxy 編輯器中查看條件式流程設定程式碼檢視：

<Flow name="Apps">
    <Description>Developer apps registered in Developer Services</Description>
    <Request/>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition>
</Flow>

如您所見，API 資源只是條件式流程，用來評估傳入要求。(proxy.pathsuffix 變數會識別位於 ProxyEndpoint 設定中設定的 BasePath)。

您定義的每項 API 資源，都是由 API Proxy 中的條件式流程實作。(詳情請參閱設定流程)。

將 API Proxy 部署至測試環境後，請提出以下要求：

http://{org_name}-test.apigee.net/{proxy_path}/apps

條件為 true、這個流程及任何相關的順利執行的政策

以下範例條件使用 Java 規則運算式，辨識對 /apps 項資源包含或沒有結尾正斜線 (/apps 或 /apps/**)：

<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>

如要進一步瞭解這類條件，請參閱 Apigee 社群中的如何忽略...。

建立階層式 URI 模型

在某些情況下，您會取得階層式 API 資源。舉例來說，開發人員服務 API 提供了一種方法，可以列出開發人員的所有應用程式。URI 路徑如下：

/developers/{developer_email}/apps

您的某些資源可能為集合中的每個實體產生專屬 ID 有時標註如下：

/genus/:id/species

這個路徑同樣適用於下列兩個 URI：

/genus/18904/species
/genus/17908/species

如要在 API 資源中表示這個結構，您可以使用萬用字元。例如：

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

會適當地將這些階層式 URI 解析為 API 資源

在某些情況下您只需要解析以下所有內容即可特定 URI 片段方法是在資源定義中使用雙星號萬用字元。適用對象舉例來說，如果您定義以下 API 資源：

/developers/**

這個 API 資源會解析下列 URI 路徑：

/developers/{developer_email}/apps
/developers/{developer_email}/keys
/developers/{developer_email}/apps/{app_id}/keys

以下是 API Proxy 定義中的條件式流程條件：

<Condition>(proxy.pathsuffix MatchesPath "/developers/**") and (request.verb = "POST")</Condition>

其他示例

條件已附加至 RouteRule

<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>

附加至政策的條件

<Step>
<!--the policy MaintenancePolicy only executes if the response status code is exactly 503-->
  <Condition>response.status.code = 503</Condition>
  <Name>MaintenancePolicy</Name>
</Step>

條件式流程

<!-- this entire flow is executed only if the request verb is a GET-->
<Flow name="GetRequests">
  <Condition>request.verb="GET"</Condition>
  <Request>
    <Step>
<!-- this policy only executes if request path includes a term like statues-->
<Condition>request.path ~ "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
<!-- this condition has multiple expressions. The policy executes if the response code status is exactly 503 or 400-->
<Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

條件中的範例運算子

以下列舉一些用來建立條件的運算子：

request.header.content-type = "text/xml"
request.header.content-length < 4096 && request.verb = "PUT"
response.status.code = 404 || response.status.code = 500
request.uri MatchesPath "/*/statuses/**"
request.queryparam.q0 NotEquals 10

實用範例：忽略「/」的路徑結尾

邊緣開發人員通常會想處理這兩個路徑後置字串：「/cat」和「/cat/」。這是因為部分使用者或用戶端可能會使用額外的程式碼來呼叫您的 API ，然後您必須能在條件式內處理聲明。這種做法都已經在 Apigee 社群討論過

您可以視需要在不使用規則運算式的情況下來達成這項目標：

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>((proxy.pathsuffix = "/cat") OR (proxy.pathsuffix = "/cat/")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

建議您採用這個選項。內容清晰可讀。

但是，您也可以透過 Regex 執行相同的動作，就像這樣。括號的用途是將內容分組與規則運算式的 regex 部分相同

<Condition>(proxy.pathsuffix JavaRegex "/cat(/?)"</Condition>

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat or
GET http://artomatic-test.apigee.net/matchtest/cat/

這項政策是否會執行？會。請注意，在規則運算式中，「?」個字元代表：比對零或前一個字元。因此「/cat」和「/cat/」。

API 呼叫：

GET http://artomatic-test.apigee.net/matchtest/cat/spotted

這項政策是否會執行？否。規則運算式會比對 00% 或 1 次開頭的字元，其他字詞則不得使用。

使用 JavaRegex 比對任意字串

在本主題的所有範例中，我們將說明如何比對其中一個內建 Flow 變數： proxy.pathsuffix.因為您可以對任意字串執行模式比對流量變數，無論變數是否為內建流程變數 (例如 proxy.pathsuffix)，

舉例來說，假設您的條件會測試任意字串，也許會傳回字串在後端酬載中，或驗證伺服器查詢所傳回的字串，您可以使用比對運算子進行測試如果您使用的是 JavaRegex，系統會比較規則運算式比對整個主旨字串如果主旨是「abc」且規則運算式為「[a-z]」沒有相符項目，因為「[a-z]」完全符合「一個」字母字元。運算式「[a-z]+」和「[a-z]*」和「[a-z]」一樣。{3}

我們來看看一個具體範例。假設驗證伺服器傳回角色清單並加上半形逗號分隔字串：「editor, author, 訪客」。

為測試是否提供編輯者角色，這項結構會無法運作，因為「編輯者」為只佔整個字串的一部分

<Condition>returned_roles ~~ "editor"</Condition>

不過，這個架構可以正常運作：

<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>

此方法會考量字詞分行和字串的其他任何部分， .* 前置字元和後置字串。

在本例中，您也可以測試「編輯器」例如：

<Condition>returned_roles ~~ "*editor*")</Condition>

不過，如果您需要更多精確度，JavaRegex 通常是更好的選擇。

在 JavaRegex 運算式中逸出雙引號

條件語法需要 JavaRegex 運算式以雙引號括住；因此包含雙引號的規則運算式運算式，就需要另一種方式來比對。答案是 Unicode 編碼。舉例來說，假設您傳入含有雙引號的標頭，如下所示：

 -H 'content-type:multipart/related; type="application/xop+xml"'

敬上如果嘗試在規則運算式條件中比對該標頭，就會收到「條件無效」錯誤，因為運算式包括雙引號：

request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"

敬上解決方法是將以 ASCII 為基礎的雙引號取代為對應的 Unicode 對應項目 \u0022。例如：下列運算式有效，會產生預期結果：

request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"

含有流程變數的條件

影片

設定條件陳述式

變數

範例 1

範例 2

測試條件式 流程

模式比對

其他資訊

運算子

相符

JavaRegex

MatchesPath

混合星號

API 資源

其他資訊

API Proxy 如何對應至特定後端資源

建立後端資源的條件式流程

建立階層式 URI 模型

其他示例

條件已附加至 RouteRule

附加至政策的條件

條件式流程

條件中的範例運算子

實用範例：忽略「/」的 路徑結尾

使用 JavaRegex 比對任意字串

在 JavaRegex 運算式中逸出雙引號

測試條件式流程

實用範例：忽略「/」的路徑結尾