API プロキシ構成リファレンス

このページは Apigee と Apigee ハイブリッドに適用されます。

Apigee Edge ドキュメントを表示する

Apigee を利用するデベロッパーの主要な開発作業には、API またはバックエンドサービスのプロキシとして機能する API プロキシの構成が含まれます。このドキュメントは、API プロキシを構築する際に利用できる、すべての構成要素のリファレンスです。

API プロキシの構築方法を学習する場合は、シンプルな API プロキシの構築のトピックから始めることをおすすめします。

次のいずれかの方法で API プロキシ構成を編集します。

Apigee UI または API を使用します。
API プロキシ構成バンドルのダウンロードとアップロードの説明に沿って、API プロキシ構成のバンドルをダウンロードして手動で編集し、新しい構成を Apigee にアップロードします。

API プロキシ構成のディレクトリ構造

API プロキシ構成のディレクトリ構造を以下に示します。

apiproxy をルートディレクトリとするディレクトリ構造。apiproxy ディレクトリの直下には、policies、proxies、resources、targets の各ディレクトリと weatherapi.xml ファイルが配置されています。

API プロキシ構成は、次の内容で構成されます。

基本構成	API プロキシのプライマリ構成設定。
ProxyEndpoint	インバウンド HTTP 接続（リクエストを行うアプリから Apigee への接続）、リクエストとレスポンスのフロー、ポリシー接続の設定。
TargetEndpoint	アウトバウンド HTTP 接続（Apigee からバックエンドサービスへの接続）、リクエストとレスポンスのフロー、ポリシー接続の設定。
フロー	ポリシーを接続できる、ProxyEndpoint と TargetEndpoint のリクエストとレスポンスのパイプライン。
ポリシー	Apigee ポリシースキーマに準拠する XML 形式の構成ファイル。
リソース	カスタムロジックを実行するためにポリシーによって参照されるスクリプト、JAR ファイル、XSLT ファイル。

基本構成

`/apiproxy/weatherapi.xml`

API プロキシの基本構成。API プロキシの名前を定義します。名前は組織内で一意でなければなりません。

構成の例:

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

基本構成の要素

名前	説明	デフォルト	必須かどうか
`APIProxy`
`name`	API プロキシの名前。組織内で一意にする必要があります。名前に使用できる文字は、`A-Za-z0-9_-` のみです。	なし	○
`revision`	API プロキシ構成のリビジョン番号。Apigee では API プロキシの現在のリビジョンが自動的にトラッキングされるため、リビジョン番号を明示的に設定する必要はありません。	なし	×
`ConfigurationVersion`	この API プロキシが準拠する API プロキシ構成スキーマのバージョン。現在サポートされている値は、majorVersion 4 と minorVersion 0 のみです。この設定は、API プロキシフォーマットの進化を可能にするため将来使用される可能性があります。	4.0	×
`Description`	API プロキシのテキストによる説明。指定すると、Apigee UI に説明が表示されます。	なし	×
`DisplayName`	API プロキシ構成の `name` 属性とは異なる場合がある、わかりやすい名前。	なし	×
`Policies`	この API プロキシの `/policies` ディレクトリにあるポリシーのリスト。通常、Apigee UI を使用して API プロキシを作成した場合にのみこの要素が表示されます。これは単なるマニフェスト設定であり、API プロキシの内容を可視化するように設計されています。	なし	×
`ProxyEndpoints`	この API プロキシの `/proxies` ディレクトリにある ProxyEndpoints のリスト。通常、Apigee UI を使用して API プロキシを作成した場合にのみこの要素が表示されます。これは単なるマニフェスト設定であり、API プロキシの内容を可視化するように設計されています。	なし	×
`Resources`	この API プロキシの `/resources` ディレクトリにあるリソース（JavaScript、Python、Java、XSLT）のリスト。通常、Apigee UI を使用して API プロキシを作成した場合にのみこの要素が表示されます。これは単なるマニフェスト設定であり、API プロキシの内容を可視化するように設計されています。	なし	×
`Spec`	API プロキシに関連付けられている OpenAPI 仕様を識別します。値は、URL または仕様ストア内のパスに設定されます。	なし	×
`TargetServers`	この API プロキシの TargetEndpoints で参照される TargetServers のリスト。通常、Apigee を使用して API プロキシを作成した場合にのみ、この要素が表示されます。これは単なるマニフェスト設定であり、API プロキシの内容を可視化するように設計されています。	なし	×
`TargetEndpoints`	この API プロキシの `/targets` ディレクトリにある TargetEndpoints のリスト。通常、Apigee UI を使用して API プロキシを作成した場合にのみこの要素が表示されます。これは単なるマニフェスト設定であり、API プロキシの内容を可視化するように設計されています。	なし	×

ProxyEndpoint

次の図は、リクエスト / レスポンスのフローを示しています。

HTTP サービスを呼び出すクライアントの図。リクエストは HTTP サービスで処理される前に、プロキシエンドポイントを経由してターゲットエンドポイントに渡されます。レスポンスはクライアントに返される前に、ターゲットエンドポイントを経由してプロキシエンドポイントに渡されます。

`/apiproxy/proxies/default.xml`

ProxyEndpoint 構成では、API プロキシのインバウンド（クライアントに対する）インターフェースが定義されます。ProxyEndpoint を構成するときに、プロキシされた 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>

基本的な ProxyEndpoint に必要な構成要素は次のとおりです。

ProxyEndpoint 構成要素

名前説明デフォルト必須かどうか

ProxyEndpoint

name ProxyEndpoint の名前。複数の ProxyEndpoints が定義されている場合（まれです）、API プロキシ構成内で一意でなければなりません。名前に使用できる文字は、A-Za-z0-9._\-$ % のみです。なし ○

PreFlow リクエストやレスポンスの PreFlow 内のポリシーを定義します。なし ○

Flows

リクエストやレスポンスの条件付きフロー内のポリシーを定義します。

なし

○

PostFlow

リクエストやレスポンスの PostFlow 内のポリシーを定義します。

なし

○

HTTPProxyConnection API プロキシに関連付けられたネットワークアドレスと URI パスを定義します。

BasePath

受信メッセージを適切な API プロキシにルーティングする際に Apigee が使用する URI パスを、一意に識別する必須文字列。

BasePath は、API プロキシのベース URL（http://apifactory-test.apigee.netなど）に追加される URI フラグメント（/weatherなど）です。BasePath は環境内で一意である必要があります。一意性は、API プロキシが生成またはインポートされたときに検証されます。

ベースパスでのワイルドカードの使用

API プロキシのベースパスでワイルドカードとして 1 つ以上の「*」を使用できます。たとえば、ベースパスを /team/*/members にすると、新しいチームに対応するために新しい API プロキシを作成する必要なく、クライアントが https://[host]/team/blue/members と https://[host]/team/green/members を呼び出せるようになります。/**/ はサポートされていないことに注意してください。

重要: Apigee では、ベースパスの最初の要素としてワイルドカード「*」を使用できません。たとえば、/*/search は使用できません。ベースパスを「*」で開始すると、Apigee による有効なパスの識別方法が原因で、予期しないエラーが発生する可能性があります。

○

Properties

オプションの HTTP 構成設定のセットは、<ProxyEndpoint> のプロパティとして定義できます。

request.queryparams.ignore.content.type.charset プロパティを使用して、リクエスト URL の処理時に Content-Type ヘッダーの charset パラメータを無視するようにプロキシに指示します。次に例を示します。


<Property name= \
"request.queryparams.ignore.content.type.charset">true</>

次の表に、charset プロパティの設定と Content-Type ヘッダーの charset パラメータの要否に応じた出力例を示します。

プロパティの設定	ヘッダー値	出力例
`charset=false`	`charset` パラメータが設定されていない	john.doe+test@gmail.com
`charset=false`	`charset=utf-8`	john.doe test@gmail.com
ヘッダーに `charset=true` が存在し、`charset` パラメータが存在しません。	`charset` パラメータが設定されていない	john.doe+test@gmail.com
`charset=true`	`charset=utf-8` パラメータが設定されている	john.doe+test@gmail.com

なし

FaultRules

ProxyEndpoint がエラーに対してどのように反応するかを定義します。障害ルールには以下の 2 つの事項を指定します。

あらかじめ定義されている障害のカテゴリ、サブカテゴリ、または名前に基づいて処理対象の障害を指定する条件。
対応する条件で使用する障害ルールの動作を定義する 1 つまたは複数のポリシー。

障害の処理をご覧ください。

なし

DefaultFaultRule

別の障害ルールによって明示的に処理されないエラー（システム、トランスポート、メッセージング、ポリシー）を処理します。

障害の処理をご覧ください。

なし

RouteRule ProxyEndpoint リクエストパイプラインによる処理後のインバウンドリクエストメッセージの宛先を定義します。通常、RouteRule は指定された TargetEndpoint、IntegrationEndpoint、または URL を指します。

Name RouteRule に名前を与える必須属性。名前に使用できる文字は、A-Za-z0-9._\-$ % のみです。たとえば、Cat2 %_ は正式名称です。なし ○

Condition 実行時の動的ルーティングに使用されるオプションの条件付きステートメント。条件付きの RouteRules は、コンテンツベースのルーティングでバックエンドのバージョニングをサポートできるようにする場合などに便利です。なし ×

TargetEndpoint

指定された TargetEndpoint 構成を識別するオプションの文字列。名前付き TargetEndpoint は、/targets ディレクトリの下にある同じ API で定義された TargetEndpoint です。

TargetEndpoint に名前を付けることによって、ProxyEndpoint リクエストパイプラインによる処理後にリクエストメッセージを転送する場所を指定します。これはオプションの設定であるので注意してください。

ProxyEndpoint は、URL を直接呼び出すことができます。たとえば、HTTP クライアントのロールで機能する JavaScript または Java リソースは、リクエストをバックエンドサービスに転送する TargetEndpoint の基本的な機能を実行できます。

なし

URL ProxyEndpoint によって呼び出されるアウトバウンドネットワークアドレスを定義するオプションの文字列。/targets に格納されている可能性のある TargetEndpoint 構成をバイパスします。なし ×

RouteRules の構成方法

名前付き TargetEndpoint は、/apiproxy/targets の下にある構成ファイルを参照し、RouteRule は ProxyEndpoint による処理後にリクエストをこのファイルに転送します。

たとえば、次の RouteRule は構成 /apiproxy/targets/myTarget.xml を参照します。

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

URL の直接呼び出し

ProxyEndpoint は、バックエンドサービスを直接呼び出すこともできます。URL の直接呼び出しは、/apiproxy/targets の下のすべての名前付き TargetEndpoints 構成をバイパスします。このため、TargetEndpoint はオプションの API プロキシ構成であっても、実際には ProxyEndpoint からの直接呼び出しは推奨されません。

たとえば、次の RouteRule は http://api.mycompany.com/v2 に対して HTTP 呼び出しを実行します。

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

条件付きルート

実行時に動的ルーティングをサポートするために、RouteRules を連結できます。インバウンドリクエストは、URL に直接ルーティングしたり、あるいは HTTP ヘッダー、メッセージコンテンツ、クエリパラメータ、時刻やロケールなどのコンテキスト情報に基づいて指定された TargetEndpoint 構成にルーティングしたり、その 2 つの組み合わせにルーティングしたりできます。

条件付き RouteRules は、Apigee の他の条件文と同様に機能します。条件リファレンスとフロー変数リファレンスをご覧ください。

たとえば、次の RouteRule の組み合わせでは、HTTP リクエストの値を検証するためにインバウンドリクエストが最初に評価されます。HTTP ヘッダー routeTo の値が TargetEndpoint1 の場合、リクエストは TargetEndpoint1 という名前の TargetEndpoint に転送されます。そうでない場合、インバウンドリクエストは 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>

null ルート

Null RouteRule を定義して、リクエストメッセージを TargetEndpoint に転送する必要がないシナリオをサポートできます。これは、ProxyEndpoint が JavaScript を使用して外部サービスを呼び出したり、API サービスの Key-Value ストアを参照してデータを取得したりするなど、ProxyEndpoint が必要なすべての処理を行う際に便利です。

たとえば、次のように null ルートを定義します。

<RouteRule name="GoNowhere"/>

条件付きの null ルートは便利です。次の例では、HTTP ヘッダー request.header.X-DoNothing に null 以外の値が設定されている場合は null ルートを実行するように構成します。

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

RouteRules は連鎖させることができるので、条件付きの null ルートは通常、条件付きルーティングをサポートするように設計された一連の RouteRules を構成する 1 つのコンポーネントになります。

条件付き null ルートを実際に使用すると、キャッシュをサポートすることになります。キャッシュポリシーによって設定された変数の値を使用することにより、エントリがキャッシュから提供されたときに null ルートを実行するように API プロキシを構成できます。

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

TargetEndpoint

TargetEndpoint は、ProxyEndpoint のアウトバウンドに相当します。TargetEndpoint は、バックエンドサービスまたは API のクライアントとして機能します。リクエストを送信し、レスポンスを受け取ります。

API プロキシに TargetEndpoints は必要ありません。ProxyEndpoints は、URL を直接呼び出すように構成できます。TargetEndpoints のない API プロキシには通常、バックエンドサービスを直接呼び出すか、Java または JavaScript を使用してサービスを呼び出すように構成された ProxyEndpoint が含まれています。

TargetEndpoint 構成

`/targets/default.xml`

TargetEndpoint は、Apigee から別のサービスまたはリソースへのアウトバウンド接続を定義します。

TargetEndpoint の構成例を次に示します。

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

TargetEndpoint の構成要素

TargetEndpoint は、次のいずれかの方法でターゲットを呼び出すことができます。

HTTP または HTTPS 呼び出しの HTTPTargetConnection
ローカルプロキシとプロキシ間のチェーンによる接続のための LocalTargetConnection

これらのいずれかを TargetEndpoint に構成します。

名前	説明	デフォルト	必須かどうか
`TargetEndpoint`
`name`	API プロキシの構成内で一意でなければならない TargetEndpoint の名前。TargetEndPoint の名前は、アウトバウンド処理のリクエストを指示するために ProxyEndpoint RouteRule で使用されます。名前に使用できる文字は、`A-Za-z0-9._\-$ %` のみです。	なし	○
`PreFlow`	リクエストやレスポンスの PreFlow 内のポリシーを定義します。	なし	○
`Flows`	リクエストやレスポンスの条件付きフロー内のポリシーを定義します。	なし	○
`PostFlow`	リクエストやレスポンスの PostFlow 内のポリシーを定義します。	なし	○
`HTTPTargetConnection`	その子要素を使用して、HTTP 経由でバックエンドリソースのリーチを指定します。 HTTPTargetConnection を使用する場合は、他のタイプのターゲット接続（ScriptTarget や LocalTargetConnection）を構成しないでください。注: `<LocalTargetConnection>` 要素は、メッセージテンプレートと呼ばれる動的な文字列置換機能をサポートしています。 `<Authentication>` 子要素を使用して、Cloud Functions や Cloud Run などの Google Cloud プロダクトで実行されている Google サービスまたはカスタムサービスへの認証済み呼び出しを行うことができます。`<Authentication>` 要素を使用するには、Google 認証システムの使用で説明されている設定とデプロイの手順が必要です。適切に設定すると、ポリシーは認証トークンを作成し、それをサービスリクエストに追加します。`<Authentication>` 要素の使用もご覧ください。
`URL`	TargetEndpoint がリクエストメッセージを転送するバックエンドサービスのネットワークアドレスを定義します。	なし	×
`LoadBalancer`	1 つ以上の名前付き TargetServer 構成を定義します。名前付き TargetServer 構成は、2 つ以上のエンドポイント構成接続を定義するロードバランシングに使用できます。 TargetServers を使用して、具体的なバックエンドサービスのエンドポイント URL から API プロキシ構成を切り離すこともできます。	なし	×
`Properties`	オプションの HTTP 構成設定のセットは、`<TargetEndpoint>` のプロパティとして定義できます。	なし	×
`SSLInfo`	必要に応じて、TargetEndpoint に TLS / SSL 設定を定義して、API プロキシとターゲットサービス間の TLS / SSL 接続を制御します。TLS / SSL TargetEndpoint 構成をご覧ください。注: `<SSLInfo>` 要素は、メッセージテンプレートと呼ばれる動的な文字列置換機能をサポートしています。	なし	×
`LocalTargetConnection`	その子要素により、ロードバランシングやメッセージプロセッサなどのネットワーク特性を考慮することなく、ローカルでアクセスするリソースを指定します。ターゲットリソースを指定するには、APIProxy 子要素（ProxyEndpoint 要素を含む）または Path 子要素のいずれかを含めます。詳細については、チェーンによる API プロキシの接続をご覧ください。 HTTPTargetConnection を使用する場合は、他のタイプのターゲット接続（LocalTargetConnection や ScriptTarget）を構成しないでください。
`APIProxy`	リクエストのターゲットとして使用する API プロキシの名前を指定します。ターゲットプロキシは、リクエストを送信するプロキシと同じ組織と環境に属している必要があります。これは Path 要素を使用する代わりに用いられる方法です。	なし	×
`ProxyEndpoint`	APIProxy とともに使用して、ターゲットプロキシの ProxyEndpoint の名前を指定します。	なし	×
`Path`	リクエストのターゲットとして使用する API プロキシのエンドポイントパスを指定します。ターゲットプロキシは、リクエストを送信するプロキシと同じ組織と環境に属している必要があります。これは、APIProxy を使用する代わりに用いられる方法です。	なし	×
`FaultRules`	TargetEndpoint がエラーに対してどのように反応するかを定義します。障害ルールには以下の 2 つの事項を指定します。あらかじめ定義されている障害のカテゴリ、サブカテゴリ、または名前に基づいて処理対象の障害を指定する条件。対応する条件で使用する障害ルールの動作を定義する 1 つまたは複数のポリシー。障害の処理をご覧ください。	なし	×
`DefaultFaultRule`	別の FaultRule によって明示的に処理されないエラー（システム、トランスポート、メッセージング、ポリシー）を処理します。障害の処理をご覧ください。	なし	×

`<Authentication>` 要素の使用

<TargetEndpoint> での <Authentication> 要素の使用方法は、ServiceCallout ポリシーでの <Authentication> 要素の使用方法と同じです。<TargetEndpoint> と ServiceCallout の両方で、<Authentication> は <HttpTargetConnection> の部分要素です。詳しくは、ServiceCallout ポリシーリファレンスの Authentication 要素をご覧ください。

`<Authentication>` 要素のエラーリファレンス

<Authentication> 要素を使用している場合は、ServiceCallout ポリシードキュメントのエラーセクションに、デプロイエラーとランタイムエラーのエラーメッセージとトラブルシューティングのヒントが記載されています。

`<Authentication>` 要素の例

次の例は、Authentication 要素を使用して、ターゲットとして Cloud Run にデプロイされたサービスを呼び出し、呼び出しの認証に必要な 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 Auth Token を生成するように構成されています。

<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 で、参照される変数が有効な変数に解決されない場合、ターゲット（クエリパラメータを除く）の URL がオーディエンスとして使用されます。リクエストパスが /foobar、TargetServer URL が https://xyz.com の場合、GoogleIDToken のオーディエンスは自動的に https://xyz.com/foobar に設定されます。

Apigee ハイブリッドユーザー: Apigee ハイブリッドを使用する場合、useTargetUrl 属性は Apigee ハイブリッドバージョン 1.8 以降のバージョンで使用できることに留意してください。

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

TLS / SSL TargetEndpoint 構成

多くの場合、TargetEndpoints では異機種のバックエンドインフラストラクチャで HTTPS 接続を管理する必要があります。このため、多くの TLS / SSL 構成設定がサポートされています。

TLS / SSL TargetEndpoint 構成要素

名前	説明	デフォルト	必須かどうか
`SSLInfo`
`Enabled`	エンドポイントに対して TLS / SSL が有効かどうかを示します。デフォルト値は、`<URL>` で HTTPS プロトコルが指定されている場合は `true`、`<URL>` で HTTP が指定されている場合は `false` です。	`<URL>` で HTTPS が指定されている場合は true	×
`Enforce`	Apigee とターゲットバックエンドの間に厳格な SSL を適用します。 `true` に設定すると、無効な証明書、期限切れの証明書、自己署名証明書、ホスト名の一致しない証明書、信頼できないルートの証明書を使用するターゲットが接続に失敗します。エラーコード `4xx` または `5xx` が返されます。未設定または `false` に設定すると、証明書に問題があるターゲットバックエンドへの接続結果は、`<IgnoreValidationErrors>` の設定によって異なります（以下をご覧ください）。`<IgnoreValidationErrors>` が `true` に設定されている場合、特定の条件下で成功レスポンス（`2xx`）が発生することがあります。	`false`	×
`TrustStore`	信頼できるサーバー証明書を含むキーストア。	なし	×
`ClientAuthEnabled`	アウトバウンドクライアント認証（双方向 TLS / SSL）を有効にする設定。	`false`	×
`KeyStore`	アウトバウンドクライアント認証に使用される秘密鍵を含むキーストア	なし	○（ClientAuthEnabled が true の場合）
`KeyAlias`	アウトバウンドクライアント認証に使用される秘密鍵のエイリアス	なし	○（ClientAuthEnabled が true の場合）
`IgnoreValidationErrors`	検証エラーが無視されるかどうかを示します。バックエンドシステムが SNI を使用し、ホスト名と一致しないサブジェクトの識別名 (DN) を持つ証明書を返す場合、エラーを無視する方法がなく、接続が失敗します。注: `<Enforce>` が `true` に設定されている場合、`<IgnoreValidationErrors>` の値は無視されます。	`false`	×
`Ciphers`	アウトバウンド TLS / SSL でサポートされている暗号。暗号が指定されていない場合、JVM で使用可能なすべての暗号が許可されます。暗号を制限するには、以下のサポートされた暗号リストから要素を追加します。 <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers>	なし	×
`Protocols`	アウトバウンド TLS / SSL でサポートされているプロトコル。プロトコルを指定されていない場合は、JVM で使用可能なすべてのプロトコルが許可されます。プロトコルを制限するには、明示的に指定します。たとえば、TLS v1.2 または TLS v1.3 のみを許可するには、次のようにします。 <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols>	なし	×

アウトバウンドクライアント認証を有効にした TargetEndpoint の例

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

詳細な手順については、TLS を構成するためのオプションをご覧ください。

フロー変数を使用した TLS / SSL 値の動的設定

TLS / SSL の詳細を動的に設定して、ランタイム要件を柔軟にサポートすることもできます。たとえば、プロキシが 2 つの異なるターゲット（テストターゲットと本番環境ターゲット）に接続する場合、API プロキシがプログラムによって呼び出し元の環境を検出し、適切なキーストアとトラストストアへの参照を動的に設定できます。この事例の詳細については、変数リファレンスを使用した TargetEndpoint の動的 SSLInfo という Apigee コミュニティにある記事をご覧ください。ここでは、デプロイ可能な API プロキシの例も示されています。

TargetEndpoint 構成で <SSLInfo> タグが設定される仕組みを示す次の例では、Java Callout、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 を使用する TargetEndpoint を構成する際は、TLS / SSL 証明書の有効期限が切れる場合や、システム構成の変更で証明書を更新しなければならなくなる場合を考慮する必要があります。

詳細については、期限切れの証明書の処理をご覧ください。

ただし、キーストアまたはトラストストアへの参照を使用するように TargetEndpoint を構成することもできます。参照を使用する利点は、別のキーストアまたはトラストストアを参照するように更新して、メッセージプロセッサを再起動することなく TLS / SSL 証明書を更新できることです。

たとえば、キーストアへの参照を使用する TargetEndpoint を次に示します。

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

ここで、OAuth 2.0 アクセストークンの取得で説明されているように、$TOKEN は 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"

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

後で別のキーストアを参照するように変更し、エイリアスの名前が同じになるようにするには、次の 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>'

ターゲットロードバランシングを行う TargetEndpoint

TargetEndpoints は、3 つのロードバランシングアルゴリズムを使用して、複数の名前付き TargetServer 間のロードバランシングを行います。

詳細な手順については、バックエンドサーバー間のロードバランシングをご覧ください。

IntegrationEndpoint

IntegrationEndpoint は、Apigee Integrationを特別に実行する TargetEndpoint です。IntegrationEndpoint を構成している場合、Apigee はリクエストオブジェクトを実行するために Apigee Integration Platform にオブジェクトに送信します。統合を実行するには、IntegrationEndpoint を構成するだけでなく、プロキシフローに SetIntegrationRequest ポリシーを追加する必要もあります。

IntegrationEndpoint 構成で <AsyncExecution> 要素を設定すると、同期的または非同期的に実行するように統合を構成できます。詳しくは、同期的実行と非同期的実行をご覧ください。統合の実行後、Apigee はレスポンスをレスポンスメッセージに保存します。

注: IntegrationEndpoint を実行するには、認証トークンが必要です。ただし、IntegrationEndpoint の定義に明示的な <Authentication> 要素はありません。Apigee は、内部でリクエストに認証トークンを追加します。IntegrationEndpoint が正常に認証されるようにするには、統合の実行に必要な IAM ロールを持つサービスアカウントで API プロキシをデプロイする必要があります。必要なロールについては、統合の IAM ロールをご覧ください。API プロキシのデプロイの詳細については、Apigee にデプロイするをご覧ください。

IntegrationEndpoint の構成

統合エンドポイントを TargetEndpoint として構成するには、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 は次のタスクを実行します。

PreFlow では、my-set-integration-request-policy という名前のポリシーを実行します。これにより、統合リクエストオブジェクトと統合フロー変数が設定されます。
RouteRule で指定されているように、my-int-endpoint をターゲットエンドポイントとして使用します。
my-set-integration-request-policy によって作成された統合リクエストオブジェクトを読み取ります。
SetIntegrationRequest ポリシーで設定されたリクエストオブジェクトとフロー変数を使用して、リクエストを Apigee Integration Platform に送信します。
統合のレスポンスをレスポンスメッセージに保存します。

<IntegrationEndpoint> 宣言を含む XML ファイルは APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/ ディレクトリにありますDevelop > API Proxies > CREATE NEW > Integration target オプションを使用して API プロキシを作成すると、Apigee は宣言を /apiproxy/integration-endpoints/default.xml ファイルに保存します。UI から統合エンドポイント XML を作成する場合は、XML ファイルにカスタム名を指定できます。

次の例では、XML ファイル内の <IntegrationEndpoint> 要素の宣言を示します。

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

IntegrationEndpoint の構成要素

名前	説明	デフォルト	必須かどうか
`IntegrationEndpoint`
`name`	IntegrationEndpoint の名前。名前に使用できる文字は `A-Za-z0-9._\-$ %` のみです。	なし	○
`AsyncExecution`	統合を同期モードと非同期モードのどちらで実行するかを指定するブール値。詳しくは、同期的実行と非同期的実行をご覧ください。	false	×

同期実行と非同期実行

この統合は、同期モードまたは非同期モードのいずれかで実行されるように構成できます。同期実行モードと非同期実行モードの相違については、<AsyncExecution> をご覧ください。

</IntegrationEndpoint> 内で <AsyncExecution> 要素を使用して、同期的実行または非同期的実行を指定します。<AsyncExecution> を true に設定すると、統合は非同期的に実行されます。false に設定すると、統合は同期的に実行されます。

次の例では、AsyncExecution を true に設定しています。

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

ポリシー

API プロキシの /policies ディレクトリには、API プロキシのフローに接続できるすべてのポリシーが含まれています。

ポリシー構成要素

名前	説明	デフォルト	必須かどうか
`Policy`
`name`	ポリシーの内部名。名前に使用できる文字は `A-Za-z0-9._\-$ %` のみです。ただし、Apigee UI には追加の制限があり、英数字以外の文字は自動的に削除されます。必要に応じて、`<DisplayName>` 要素を使用して、Apigee UI プロキシエディタでポリシーに別の自然言語名でラベルを付けます。	なし	○
`enabled`	ポリシーを適用するには、`true` に設定します。ポリシーを無効にするには、`false` に設定します。ポリシーがフローに接続されている場合でも適用されません。	`true`	×
`continueOnError`	ポリシーが失敗したときにエラーを返す場合は、`false` に設定します。これは、ほとんどのポリシーで想定される動作です。ポリシーが失敗した後もフローの実行を続行する場合は、`true` に設定します。	`false`	×
`async`	注: この属性によってポリシーが非同期に実行されることはありません。ほとんどの場合、デフォルトの `false` のままにしておきます。 `true` に設定すると、ポリシーの実行が別のスレッドにオフロードされ、メインスレッドは追加のリクエストを処理できるようになります。オフライン処理が完了すると、メインスレッドが戻ってメッセージフローの処理を終了します。場合によっては、非同期を `true` に設定すると、API プロキシのパフォーマンスが向上することがあります。だだし、非同期を過度に使用すると、スレッド切り替えが多くなりすぎてパフォーマンスが低下する可能性があります。 API プロキシで非同期の動作を使用するには、JavaScript オブジェクトモデルをご覧ください。	`false`	×

ポリシー接続

次の図は、API プロキシフローの実行順序を示しています。

HTTP サービスを呼び出すクライアントの図。リクエストは ProxyEndpoint と TargetEndpoint に渡されます。これら 2 つのエンドポイントのそれぞれに、ポリシーをトリガーするステップが含まれています。HTTP サービスからレスポンスが返されると、そのレスポンスは TargetEndpoint で処理され、続いて ProxyEndpoing で処理されてからクライアントに返されます。リクエストの場合と同じく、レスポンスはステップ内でポリシーによって処理されます。

上記のフローの説明:

ポリシーは Flow への処理ステップとして接続されます。ポリシーの名前は、処理ステップとして実施されるポリシーを参照するために使用されます。ポリシー接続の形式は次のとおりです。

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

ポリシーは Flow に接続されている順序で適用されます。次に例を示します。

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

ポリシー接続の構成要素

名前	説明	デフォルト	必須かどうか
`Step`
`Name`	このステップ定義によって実行されるポリシーの名前。	なし	○
`Condition`	ポリシーが適用されているかどうかを判断する条件文。ポリシーに関連する条件がある場合、条件文が true と評価されればポリシーが実行されます。	なし	×

フロー

ProxyEndpoint と TargetEndpoint は、リクエストとレスポンスのメッセージを処理するためのパイプラインを定義します。処理パイプラインは、リクエストフローとレスポンスフローで構成されます。各リクエストフローとレスポンスフローは PreFlow、1 つ以上のオプションの条件または名前付フローと PostFlow に細分化されます。

PreFlow: 常に実行します。条件付きフローの前に実行されます。
PostFlow: 常に実行されます。条件付きフローの後に実行されます。

さらに、ProxyEndpoint に PostClientFlow を追加できます。ProxyEndpoint は、レスポンスが要求元のクライアントアプリに返された後に実行されます。このフローには、MessageLogging ポリシーのみを追加できます。PostClientFlow によって API プロキシのレイテンシは短縮されます。また、レスポンスがクライアントに返されるまでは計算されないロギング（client.sent.start.timestamp や client.sent.end.timestamp など）に情報を提供できるようになります。このフローは主に、レスポンスメッセージの開始と終了のタイムスタンプの間隔を測定するために使用されます。

Message Logging ポリシーが接続されている PostClientFlow の例を次に示します。

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

API プロキシ処理パイプラインは、次の順序でフローを実行します。

リクエストパイプライン:

プロキシリクエスト PreFlow
プロキシリクエストの条件付きフロー（オプション）
プロキシリクエスト PostFlow
ターゲットリクエスト PreFlow
ターゲットリクエストの条件付きフロー（オプション）
ターゲットリクエスト PostFlow

レスポンスパイプライン:

ターゲットレスポンス PreFlow
ターゲットレスポンスの条件付きフロー（オプション）
ターゲットレスポンス PostFlow
プロキシレスポンス PreFlow
プロキシレスポンスの条件付きフロー（オプション）
プロキシレスポンス PostFlow
PostClientFlow レスポンス（オプション）

ProxyEndpoint または TargetEndpoint の構成では、ポリシー接続を持つフローのみを構成する必要があります。PreFlow または PostFlow 処理中にポリシーを適用する必要がある場合は、PreFlow と PostFlow を ProxyEndpoint または TargetEndpoint 構成でのみ指定します。

条件フローとは対照的に、PreFlow 要素と PostFlow 要素の順序は重要ではありません。API プロキシは、エンドポイント構成のどこに表示されるかにかかわらず、パイプラインの適切なポイントでそれぞれを常に実行します。

条件フロー

ProxyEndpoints と TargetEndpoints は、条件フロー（または名前付きフロー）を無制限にサポートします。

API プロキシでは、条件フローに指定されている条件がテストされます。条件が満たされると、条件フローの処理ステップが API プロキシによって実行されます。条件が満たされない場合は、条件付きフローのその処理ステップは省略されます。条件付きフローは API プロキシで定義されている順に評価され、条件が最初に満たされたフローが実行されます。

条件付きフローを定義することにより、次に基づいて、API プロキシに処理ステップを適用できます。

リクエスト 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>

フロー構成要素

名前	説明	デフォルト	必須かどうか
`Flow`	ProxyEndpoint または TargetEndpoint によって定義されたリクエストまたはレスポンス処理パイプライン
`Name`	フローの一意の名前。	なし	○
`Condition`	true または false を評価するための変数を評価する条件文。事前定義済みの PreFlow と PostFlow タイプ以外のすべてのフローは、実行条件を定義する必要があります。	なし	○
`Request`	リクエストメッセージ処理に関連するパイプライン	なし	×
`Response`	レスポンスメッセージ処理に関連するパイプライン	なし	×

ステップ処理

条件フローの順序づけは、Apigee によって適用されます。条件フローは上から下に実行されます。条件が true と評価される最初の条件付きフローが実行され、1 つの条件付きフローのみが実行されます。

たとえば、次のフロー構成では、パス接尾辞 /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 プロキシで使用するリソースファイル）は、ポリシーを使用してフローに接続できるスクリプト、コード、XSL 変換です。これらは、Apigee UI の API プロキシエディタの [Scripts] セクションに表示されます。

サポートされるリソースタイプについては、リソースの管理をご覧ください。

リソースは、API プロキシ、環境、組織のいずれかに保存できます。いずれの場合も、リソースはポリシー内で名前によって参照されます。Apigee は、API プロキシから環境、組織レベルに移動して名前を解決します。

組織レベルで格納されたリソースは、どの環境のポリシーでも参照できます。環境レベルで格納されたリソースは、その環境のポリシーによって参照されます。API プロキシレベルで格納されたリソースは、その API プロキシ内のポリシーによってのみ参照できます。