API Proxy 設定參考資料

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本頁適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

身為 Apigee 開發人員，您的主要開發活動包括設定 API Proxy，以便做為 API 或後端服務的 Proxy。本文是建構 API Proxy 時可用的所有設定元素參考資料。

如果您想瞭解如何建構 API Proxy，建議您先參閱「建構簡單的 API Proxy」一文。

請使用下列任一方法編輯 API Proxy 設定：

• 使用 Apigee UI 或 API。
• 請按照「下載及上傳 API Proxy 設定套件」一文的說明，下載 API Proxy 設定套件並手動編輯，然後將新設定上傳至 Apigee。

API Proxy 設定目錄結構

API Proxy 設定目錄結構如下所示：

API Proxy 設定包含以下內容：

基本設定

/apiproxy/weatherapi.xml

API Proxy 的基本設定，用於定義 API Proxy 的名稱。名稱不得重複。

設定範例：

<APIProxy name="weatherapi">
</APIProxy>

基礎設定元素

ProxyEndpoint

下圖顯示要求/回應流程：

/apiproxy/proxies/default.xml

ProxyEndpoint 設定會定義 API Proxy 的入站 (面向用戶端) 介面。設定 Proxy 端點時，您會設定網路設定，定義用戶端應用程式 (apps) 應如何叫用 Proxy API。

下列 ProxyEndpoint 設定範例會儲存在 /apiproxy/proxies 下：

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

基本 Proxy 端點中必要的設定元素如下：

ProxyEndpoint 設定元素

如何設定 RouteRules

命名的目標端點是指 /apiproxy/targets 底下的設定檔，RouteRule 會在代理程式端點處理要求後，將要求轉送至該檔案。

例如，下列 RouteRule 會參照 /apiproxy/targets/myTarget.xml 設定：

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

直接網址叫用

Proxy 端點也可以直接叫用後端服務。直接呼叫網址會略過 /apiproxy/targets 下任何名為 TargetEndpoint 的設定。因此，TargetEndpoint 是可選的 API Proxy 設定，但在實際操作中，我們不建議從 Proxy 端點直接呼叫。

舉例來說，下列 RouteRule 會對 http://api.mycompany.com/v2 發出 HTTP 呼叫。

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

條件式路徑

RouteRules 可鏈結，以便在執行階段支援動態路由。根據 HTTP 標頭、訊息內容、查詢參數或時區等背景資訊，您可以將傳入要求路由至命名的 TargetEndpoint 設定、直接路由至網址，或兩者皆是。

條件式 RouteRules 的運作方式與 Apigee 上的其他條件式陳述式相同。請參閱「條件參考資料」和「流程變數參考資料」。

舉例來說，下列 RouteRule 組合會先評估內送要求，以驗證 HTTP 標頭的值。如果 HTTP 標頭 routeTo 的值為 TargetEndpoint1，則要求會轉送至名為 TargetEndpoint1 的目標端點。如果沒有，則會將內送要求轉送至 http://api.mycompany.com/v2。

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

空值路徑

您可以定義空值 RouteRule，以支援不需將要求訊息轉送至目標端點的情況。當 Proxy 端點執行所有必要的處理作業時，這項功能就非常實用，例如使用 JavaScript 呼叫外部服務，或從 Apigee 鍵/值儲存庫的查詢中擷取資料。

例如，以下定義為空值的 Route：

<RouteRule name="GoNowhere"/>

條件式空值路徑可能很實用。在以下範例中，當 HTTP 標頭 request.header.X-DoNothing 的值為 null 以外的值時，系統會執行空值路徑。

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

請注意，RouteRules 可連結，因此條件式空值 Route 通常是設計用於支援條件式轉送的 RouteRules 集合的其中一個元件。

實際使用條件為空值的路徑，可支援快取。您可以使用 Cache 政策設定的變數值，設定 API 代理程式，在從快取提供項目時執行 null 路徑。

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

目標端點是 Proxy 端點的出站等價。目標端點會做為後端服務或 API 的用戶端，負責傳送要求並接收回應。

API Proxy 不需要任何目標端點。您可以設定 Proxy 端點，直接呼叫網址。沒有目標端點的 API Proxy 通常會包含 Proxy 端點，該端點會直接呼叫後端服務，或設定為使用 Java 或 JavaScript 呼叫服務。

TargetEndpoint 設定

/targets/default.xml

目標端點會定義從 Apigee 到其他服務或資源的傳出連線。

以下是 TargetEndpoint 設定範例：

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

TargetEndpoint 設定元素

目標端點可以透過下列任一方式呼叫目標：

• 用於 HTTP 或 HTTPS 呼叫的 HTTPTargetConnection
• 用於本機 Proxy 對 Proxy 連結的 LocalTargetConnection

在目標端點中只設定其中一個。

<Properties>
  <Property name="response.payload.parse.limit">15M</Property>
</Properties>

<Authentication> 元素用法

<Authentication> 元素錯誤參考資料

如果您使用 <Authentication> 元素，請參閱 ServiceCallout 政策文件的「Errors」部分，瞭解可能的錯誤訊息，以及如何排解部署和執行階段錯誤。

<Authentication> 元素範例

以下範例說明如何呼叫在 Cloud Run 上部署的服務做為目標，並使用 Authentication 元素產生 OpenID Connect 權杖，用於驗證呼叫：

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

以下範例說明如何使用 Authentication 元素，呼叫指向 Cloud Run 的 TargetService，以產生驗證呼叫所需的 OpenID Connect 權杖。HeaderName 元素會將產生的權杖權杖新增至傳送至目標系統的 X-Serverless-Authorization 標頭。如果有 Authorization 標頭，則會保留不變，並一併傳送至要求中。

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

以下範例說明如何呼叫指向 Google Secret Manager 服務的 TargetService。在這個範例中，GoogleAccessToken 元素會設定為產生 Google 驗證權杖，以便驗證目標要求：

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

以下範例說明如何自動設定 GoogleIDToken 的目標對象。如果 useTargetUrl 為 true，且參照的變數未解析為有效變數，則會使用目標的網址 (不含查詢參數) 做為目標對象。假設要求路徑為 /foobar，目標伺服器網址為 https://xyz.com，GoogleIDToken 的目標對象就會自動設為 https://xyz.com/foobar。

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

TLS/SSL TargetEndpoint 設定

目標端點通常需要管理 HTTPS 連線與異質後端基礎架構。因此，我們支援多個 TLS/SSL 設定。

TLS/SSL 目標端點設定元素

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

指定環境層級的 SSL 強制執行機制

如果 SSLInfo.Enforce 設為 true 或 false，則指定的值會覆寫 TargetEndpoint 或 TargetServer 設定中 <SSLInfo> 區塊中指定的任何精細執行選項。

如果未設定 SSLInfo.Enforce，SSL 強制執行機制會根據個別 <SSLInfo> 區塊中使用 <Enforce> 元素指定的任何值決定。詳情請參閱 TLS/SSL TargetEndpoint 設定。

在以下範例中，SSLInfo.Enforce 已設為 true。在產生的輸出內容中，您可以看到 SSL 已在指定環境中強制執行。

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'
  

輸出：

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

已啟用出站用戶端驗證的目標端點範例

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

如需詳細操作說明，請參閱「 傳輸層安全標準 (TLS) 設定選項」。

使用資料流變數動態設定 TLS/SSL 值

您也可以動態設定 TLS/SSL 詳細資料，以便支援彈性的執行階段需求。舉例來說，如果 Proxy 連線至兩個可能不同的目標 (測試目標和正式目標)，您可以讓 API Proxy 以程式輔助方式偵測所呼叫的環境，並動態設定適當的 KeyStore 和 TrustStore 參照。Apigee 社群文章「 使用變數參照為 TargetEndpoint 提供動態 SSLInfo」進一步說明這個情況，並提供可部署的 API 代理程式範例。

以下範例說明如何在 TargetEndpoint 設定中設定 <SSLInfo> 標記，在執行階段提供值，例如透過 Java 呼叫、JavaScript 政策或 AssignMessage 政策。請使用含有您要設定值的任何訊息變數。

變數只能用於下列元素。

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

使用參照動態設定 TLS/SSL 值

設定使用 HTTPS 的目標端點時，您必須考量 TLS/SSL 憑證到期或系統設定變更時，您需要更新憑證的情況。

詳情請參閱「 處理已過期憑證」。

不過，您可以選擇將目標端點設定為改用金鑰庫或信任庫的參照。使用參照的優點是，您可以更新參照，讓其指向其他金鑰庫或信任庫，藉此更新 TLS/SSL 憑證，而無須重新啟動訊息處理器。

舉例來說，下方顯示的是使用金鑰庫參照的目標端點：

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

請使用下列 POST API 呼叫，建立名為 keystoreref 的參照：

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

其中 $TOKEN 會設為您的 OAuth 2.0 存取權憑證，如取得 OAuth 2.0 存取權憑證一文所述。如要瞭解本範例中使用的 curl 選項，請參閱「使用 curl」。如要瞭解所使用的環境變數，請參閱「為 Apigee API 要求設定環境變數」。

參照會指定金鑰庫的名稱和類型。

請使用下列 GET API 呼叫來查看參照資料：

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

其中 $TOKEN 會設為您的 OAuth 2.0 存取權憑證，如取得 OAuth 2.0 存取權憑證一文所述。如要瞭解本範例中使用的 curl 選項，請參閱「使用 curl」。如要瞭解所使用的環境變數，請參閱「為 Apigee API 要求設定環境變數」。

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

其中 $TOKEN 會設為您的 OAuth 2.0 存取權憑證，如取得 OAuth 2.0 存取權憑證一文所述。如要瞭解本範例中使用的 curl 選項，請參閱「使用 curl」。如要瞭解所使用的環境變數，請參閱「為 Apigee API 要求設定環境變數」。

如要日後變更參照，以便指向不同的 KeyStore，並確保別名具有相同的名稱，請使用下列 PUT 呼叫：

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

其中 $TOKEN 會設為您的 OAuth 2.0 存取權憑證，如取得 OAuth 2.0 存取權憑證一文所述。如要瞭解本範例中使用的 curl 選項，請參閱「使用 curl」。如要瞭解所使用的環境變數，請參閱「為 Apigee API 要求設定環境變數」。

搭配目標負載平衡功能的 TargetEndpoint

目標端點支援使用三種負載平衡演算法，在多個已命名的目標伺服器上進行負載平衡。

如需詳細操作說明，請參閱「 跨後端伺服器負載平衡」。

IntegrationEndpoint

IntegrationEndpoint 是專門用於執行 Apigee 整合的目標端點。如果您已設定 IntegrationEndpoint，Apigee 會將 request 物件傳送至 Apigee 的整合平台執行。如要執行整合，除了設定 IntegrationEndpoint 之外，您還必須在 Proxy 流程中新增 SetIntegrationRequest 政策。

您可以在 IntegrationEndpoint 設定中設定 <AsyncExecution> 元素，讓整合作業以同步或非同步方式執行。詳情請參閱「同步執行與非同步執行」。執行整合作業後，Apigee 會將回應儲存在回應訊息中。

設定 IntegrationEndpoint

如要將整合端點設為目標端點，請將 IntegrationEndpoint 元素新增至 ProxyEndpoint 設定。以下是 ProxyEndpoint 設定範例：

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

在 ProxyEndpoint 設定範例中，Apigee 會執行下列工作：

1. 在 PreFlow 中執行名為 my-set-integration-request-policy 的政策，該政策會設定整合要求物件和整合流程變數。
2. 使用 my-int-endpoint 做為目標端點，如 RouteRule 所指定。
3. 讀取 my-set-integration-request-policy 建立的整合要求物件。
4. 使用 SetIntegrationRequest 政策設定的要求物件和流程變數，將要求傳送至 Apigee 的整合平台。
5. 將整合項目的回應儲存在回應訊息中。

包含 <IntegrationEndpoint> 宣告的 XML 檔案會在 APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/ 目錄中提供。如果您使用 Develop > API Proxies > CREATE NEW > Integration target 選項建立 API Proxy，Apigee 會將宣告儲存在 /apiproxy/integration-endpoints/default.xml 檔案中。如果您是透過使用者介面建立整合端點 XML，可以為 XML 檔案提供自訂名稱。

以下範例顯示 XML 檔案中的 <IntegrationEndpoint> 元素宣告：

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

IntegrationEndpoint 設定元素

同步執行與非同步執行

您可以設定整合作業以同步或非同步模式執行。如要瞭解同步和非同步執行模式的差異，請參閱 <AsyncExecution>。

請使用 </IntegrationEndpoint> 中的 <AsyncExecution> 元素指定同步或非同步執行作業。如果您將 <AsyncExecution> 設為 true，整合作業會以非同步方式執行。如果將其設為 false，整合作業就會以同步方式執行。

以下範例會將 AsyncExecution 設為 true：

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

政策

API Proxy 中的 /policies 目錄包含可附加至 API Proxy 中流程的所有政策。

政策設定元素

政策附加

下圖顯示 API 代理程式流程的執行順序：

如上所示：

政策會以處理步驟的形式附加至流程。政策名稱用於參照要以處理步驟方式強制執行的政策。政策附件的格式如下：

<Step><Name>MyPolicy</Name></Step>

系統會依附加至流程的順序強制執行政策。例如：

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

政策附件設定元素

流程

ProxyEndpoint 和 TargetEndpoint 會定義要求和回應訊息處理的管道。處理管道包含要求流程和回應流程。每個要求流程和回應流程都會細分為 PreFlow、一或多個選用的條件或命名流程，以及 PostFlow。

• PreFlow：一律執行。會在任何條件式流程之前執行。
• PostFlow：一律執行。在任何條件式流程後執行。

此外，您也可以在 Proxy 端點中新增 PostClientFlow，該流程會在回應傳回至要求的用戶端應用程式後執行。只有 MessageLogging 政策可以附加至此流程。PostClientFlow 可減少 API 代理延遲時間，並提供可用於記錄的資訊，這些資訊會在回應傳回至用戶端 (例如 client.sent.start.timestamp 和 client.sent.end.timestamp) 後才計算。這項流程主要用於測量回應訊息開始和結束時間戳記之間的時間間隔。

以下是附加訊息記錄政策的 PostClientFlow 範例。

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

API 代理處理管道會按照以下順序執行流程：

要求管道：

1. Proxy Request PreFlow
2. Proxy Request 條件式流程 (選用)
3. Proxy Request PostFlow
4. 目標要求預檢
5. 指定要求條件流程 (選用)
6. 目標請求後續流程

回應管道：

1. 目標回覆預先流程
2. 指定回應條件式流程 (選用)
3. 目標回應 PostFlow
4. Proxy Response PreFlow
5. Proxy Response 條件流程 (選用)
6. Proxy Response PostFlow
7. PostClientFlow 回應 (選用)

只有含有政策附件的流程才需要在 ProxyEndpoint 或 TargetEndpoint 設定中進行設定。只有在 PreFlow 或 PostFlow 處理期間需要強制執行政策時，才需要在 ProxyEndpoint 或 TargetEndpoint 設定中指定 PreFlow 和 PostFlow。

與條件式流程相反，PreFlow 和 PostFlow 元素的順序並不重要，因為 API 代理程式會在管道中適當的點執行每個元素，無論這些元素在 Endpoint 設定中顯示的位置為何。

條件式流程

Proxy 端點和目標端點支援無限數量的條件式流程 (也稱為命名流程)。

API Proxy 會測試條件式流程中指定的條件，如果符合條件，API Proxy 就會執行條件式流程中的處理步驟。如果條件不符合，系統會略過條件式流程中的處理步驟。系統會依據 API Proxy 中定義的順序評估條件式流程，並執行符合條件的第 1 個流程。

定義條件式流程後，您就能根據下列項目在 API Proxy 中套用處理步驟：

• 要求 URI
• HTTP 動詞 (GET/PUT/POST/DELETE)
• 查詢參數、標頭和表單參數的值
• 許多其他類型的條件

舉例來說，下列條件式流程會指定只在要求資源路徑為 /accesstoken 時執行。任何路徑為 /accesstoken 的傳入要求都會導致系統執行這個流程，以及附加至流程的任何政策。如果要求路徑不含 /accesstoken 後置字串，則不會執行這項流程 (但其他條件式流程可能會執行)。

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

流程設定元素

步驟處理

Apigee 會強制執行條件式流程的順序。條件式流程會由上而下執行。系統會執行條件評估為 true 的第一個條件式流程，且只會執行一個條件式流程。

舉例來說，在下列流程設定中，任何不含路徑後置字串 /first 或 /second 的內送要求都會導致 ThirdFlow 執行，並強制執行名為 Return404 的政策。

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

資源

「資源」(可用於 API Proxy 的資源檔案) 是指可使用政策附加至流程的指令碼、程式碼和 XSL 轉換。這些會顯示在 Apigee UI 中 API Proxy 編輯器的「Scripts」部分。

如要瞭解支援的資源類型，請參閱「管理資源」。

資源可儲存在 API Proxy、環境或機構中。在每個情況下，資源都會在政策中以名稱參照。Apigee 會從 API Proxy 開始，依序在環境和機構層級解析名稱。

儲存在機構層級的資源，可供任何環境中的政策參照。儲存在環境層級的資源可供該環境中的政策參照。儲存在 API Proxy 層級的資源，只能由該 API Proxy 中的政策參照。