API 프록시 구성 참조

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee Edge 문서 보기

Apigee를 사용하는 개발자의 주요 개발 활동에는 API 또는 백엔드 서비스의 프록시로 작동하는 API 프록시를 구성하는 작업이 포함됩니다. 이 문서는 API 프록시를 빌드할 때 사용할 수 있는 모든 구성 요소에 대한 참고 자료입니다.

API 프록시를 빌드하는 방법을 알아보려면 간단한 API 프록시 빌드 주제로 시작하는 것을 추천합니다.

다음 방법 중 하나를 사용하여 API 프록시 구성을 수정합니다.

• Apigee UI 또는 API를 사용합니다.
• API 프록시 구성 번들 다운로드 및 업로드에 설명된 대로 API 프록시 구성 번들을 다운로드하고 수동으로 수정하며 새 구성을 Apigee에 업로드합니다.

API 프록시 구성 디렉터리 구조

API 프록시 구성 디렉터리 구조는 다음과 같습니다.

API 프록시 구성은 다음 콘텐츠로 구성됩니다.

기본 구성

/apiproxy/weatherapi.xml

API 프록시의 기본 구성으로, API 프록시의 이름을 정의합니다. 이름은 조직 내에서 고유해야 합니다.

샘플 구성:

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

기본 구성 요소

ProxyEndpoint

다음 이미지에서는 요청/응답 흐름을 보여줍니다.

/apiproxy/proxies/default.xml

ProxyEndpoint 구성은 API 프록시의 인바운드(클라이언트 연결) 인터페이스를 정의합니다. 프록시 엔드포인트를 구성할 때 네트워크 구성을 설정하여 클라이언트 애플리케이션(앱)이 프록시된 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 구성 요소

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

RouteRule 구성 방법

명명된 대상 엔드포인트는 /apiproxy/targets 아래 구성 파일을 나타내며, RouteRule은 프록시 엔드포인트에서 요청을 처리한 후 구성 파일로 전달합니다.

예를 들어 다음 RouteRule은 /apiproxy/targets/myTarget.xml 구성을 나타냅니다.

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

직접 URL 호출

프록시 엔드포인트는 백엔드 서비스를 직접 호출할 수도 있습니다. 직접 URL 호출은 /apiproxy/targets에 있는 명명된 TargetEndpoints 구성을 우회합니다. 따라서 TargetEndpoint는 선택적 API 프록시 구성이지만 실제로는 프록시 엔드포인트의 직접 호출은 권장되지 않습니다.

예를 들어 다음 RouteRule은 http://api.mycompany.com/v2에 대한 HTTP 호출을 수행합니다.

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

조건부 경로

RouteRule을 체인으로 연결하여 런타임 시 동적 라우팅을 지원할 수 있습니다. HTTP 헤더, 메시지 콘텐츠, 쿼리 매개변수 또는 시간, 로케일 등의 문맥 정보를 기반으로 명명된 TargetEndpoint 구성, URL 또는 두 개의 조합에 인바운드 요청을 라우팅할 수 있습니다.

조건부 RouteRule은 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>

null 경로

요청 메시지를 대상 엔드포인트로 전달할 필요가 없는 시나리오를 지원하려면 null RouteRule을 정의할 수 있습니다. 예를 들어 프록시 엔드포인트가 JavaScript를 사용하여 외부 서비스를 호출하거나 Apigee 키/값 저장소 조회를 통해 데이터를 검색하는 등 필요한 모든 처리를 수행할 때 유용합니다.

예를 들어 다음은 null 경로를 정의합니다.

<RouteRule name="GoNowhere"/>

조건부 null 경로가 유용할 수 있습니다. 다음 예시에서 HTTP 헤더 request.header.X-DoNothing가 null 외의 값이 있는 경우 null 경로를 구성하여 실행합니다.

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

RouteRule은 연결할 수 있으므로 조건부 null 경로는 일반적으로 조건부 라우팅을 지원하도록 설계된 RouteRule 집합의 한 가지 구성요소가 됩니다.

조건부 null 경로를 실무에서 사용할 경우 캐싱이 지원됩니다. 캐시 정책으로 설정한 변수 값을 사용하면 캐시에서 항목을 제공할 때 null 경로를 실행하도록 API 프록시를 구성할 수 있습니다.

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

TargetEndpoint

대상 엔드포인트는 프록시 엔드포인트의 아웃바운드 버전입니다. 대상 엔드포인트는 백엔드 서비스 또는 API에 대한 클라이언트 역할을 하며 요청을 전송하고 응답을 수신합니다.

API 프록시에는 대상 엔드포인트가 필요하지 않습니다. 프록시 엔드포인트는 URL을 직접 호출하도록 구성할 수 있습니다. 대상 엔드포인트가 없는 API 프록시에는 일반적으로 백엔드 서비스를 직접 호출하거나 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
• 프록시와 프록시 간의 로컬 연결을 위한 LocalTargetConnection

이 중 하나만 대상 엔드포인트에서 구성합니다.

<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 요소가 생성된 Bearer 토큰을 대상 시스템으로 전송되는 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이고 참조된 변수가 유효한 변수로 확인되지 않으면 대상의 URL(쿼리 매개변수 제외)이 대상으로 사용됩니다. 요청 경로가 /foobar이고 대상 서버 URL이 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 TargetEndpoint 구성 요소

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

아웃바운드 클라이언트 인증을 사용하는 샘플 대상 엔드포인트

<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 세부정보를 동적으로 설정하여 유연한 런타임 요구사항을 지원할 수도 있습니다. 예를 들어 프록시가 잠재적으로 상이한 두 개의 대상(테스트 대상 및 프로덕션 대상)에 연결하는 경우 API 프록시를 통해 호출 중인 환경을 프로그래매틱 방식으로 감지하고 적절한 키 저장소 및 트러스트 저장소에 대한 참조를 동적으로 설정할 수 있습니다. 변수 참조를 사용하는 TargetEndpoint용 동적 SSLInfo Apigee 커뮤니티 문서에서는 이 시나리오를 자세히 설명하고 배포할 수 있는 API 프록시 예시를 제공합니다.

TargetEndpoint 구성에서 <SSLInfo> 태그가 설정되는 방식에 대한 다음 예시에서는 가령 자바 콜아웃, 자바스크립트 정책, 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 요청에 대한 환경 변수 설정을 참조하세요.

다른 키 저장소를 가리키도록 나중에 참조를 변경하여 별칭의 이름을 동일하게 하려면 다음 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 Integration을 실행하는 대상 엔드포인트입니다. IntegrationEndpoint를 구성한 경우 Apigee가 요청 객체를 실행하도록 Apigee의 통합 플랫폼으로 전송합니다. 통합을 실행하려면 IntegrationEndpoint 구성 외에도 프록시 흐름에 SetIntegrationRequest 정책을 추가해야 합니다.

IntegrationEndpoint 구성에서 <AsyncExecution> 요소를 설정하여 동기적 또는 비동기적으로 실행할 통합을 구성할 수 있습니다. 자세한 내용은 동기적 실행 및 비동기적 실행 비교를 참조하세요. 통합을 실행한 후에는 Apigee가 응답을 응답 메시지에 저장합니다.

IntegrationEndpoint 구성

통합 엔드포인트를 대상 엔드포인트로 구성하려면 ProxyEndpoint 구성에 IntegrationEndpoint 요소를 추가합니다. 다음은 샘플 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. RouteRule에 지정된 대로 my-int-endpoint를 대상 엔드포인트로 사용합니다.
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 프록시를 만드는 경우 Apigee가 /apiproxy/integration-endpoints/default.xml 파일에 선언을 저장합니다. UI에서 통합 엔드포인트 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 프록시의 /policies 디렉터리에는 API 프록시의 흐름에 연결할 수 있는 모든 정책이 포함됩니다.

정책 구성 요소

정책 연결

다음 이미지에서는 API 프록시 흐름 실행 시퀀스를 보여줍니다.

다음은 위 그림에 대한 설명입니다.

정책은 흐름의 처리 단계로 연결됩니다. 정책 이름은 처리 단계에서 적용할 정책을 참조하는 데 사용됩니다. 정책 연결 형식은 다음과 같습니다.

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

정책은 흐름에 연결된 순서대로 적용됩니다. 예를 들면 다음과 같습니다.

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

정책 연결 구성 요소

흐름

ProxyEndpoint 및 TargetEndpoint는 요청 및 응답 메시지 처리를 위한 파이프라인을 정의합니다. 처리 파이프라인은 요청 흐름과 응답 흐름으로 구성됩니다. 각 요청 흐름과 응답 흐름은 PreFlow, 하나 이상의 선택적 조건부 또는 이름이 지정된 흐름, PostFlow로 세분화됩니다.

• PreFlow: 항상 실행됩니다. 조건부 흐름 전에 실행됩니다.
• PostFlow: 항상 실행됩니다. 조건부 흐름 후에 실행됩니다.

또한 요청 클라이언트 앱에 응답이 반환된 후에 실행되는 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. 프록시 요청 PreFlow
2. 프록시 요청 조건부 흐름(선택사항)
3. 프록시 요청 PostFlow
4. 대상 요청 PreFlow
5. 대상 요청 조건부 흐름(선택사항)
6. 대상 요청 PostFlow

응답 파이프라인:

1. 대상 응답 PreFlow
2. 대상 응답 조건부 흐름(선택사항)
3. 대상 응답 PostFlow
4. 프록시 응답 PreFlow
5. 프록시 응답 조건부 흐름(선택사항)
6. 프록시 응답 PostFlow
7. PostClientFlow 응답(선택사항)

정책이 연결된 흐름만 ProxyEndpoint 또는 TargetEndpoint 구성에서 구성해야 합니다. PreFlow 및 PostFlow는 PreFlow 또는 PostFlow 처리 중에 정책을 적용해야 하는 경우 ProxyEndpoint 또는 TargetEndpoint 구성에서만 지정해야 합니다.

조건부 흐름과 달리 PreFlow 및 PostFlow 요소의 순서는 중요하지 않습니다. API 프록시는 엔드포인트 구성에서 나타나는 위치와 관계없이 항상 파이프라인의 적절한 지점에서 실행됩니다.

조건부 흐름

프록시 엔드포인트 및 대상 엔드포인트는 제한된 수의 조건부 흐름(이름이 지정된 흐름이라고도 함)을 지원합니다.

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>   

흐름 구성 요소

단계 처리

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 프록시에서 사용할 리소스 파일)는 정책을 사용하여 흐름에 연결할 수 있는 스크립트, 코드, XSL 변환입니다. 이는 Apigee UI의 API 프록시 편집기에 있는 스크립트 섹션에 나타납니다.

지원되는 리소스 유형은 리소스 관리를 참조하세요.

리소스는 API 프록시, 환경, 조직에 저장될 수 있습니다. 각각의 경우 리소스는 정책의 이름을 기준으로 참조됩니다. Apigee는 API 프록시로부터 환경, 조직 수준으로 이동하여 이름을 확인합니다.

조직 수준에 저장된 리소스는 모든 환경의 정책을 기준으로 참조될 수 있습니다. 환경 수준에 저장된 리소스는 이 환경의 정책을 기준으로 참조될 수 있습니다. API 프록시 수준에 저장된 리소스는 이 API 프록시의 정책을 기준으로만 참조될 수 있습니다.