API 프록시 구성 참조

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

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

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

프록시 구성을 수정하는 가장 일반적인 방법은 다음과 같습니다.

• Edge UI 내에서 XML 편집기 사용
• 프록시 구성의 로컬 개발에 설명된 대로 구성을 다운로드하고 로컬에서 수정합니다.

프록시 구성 로컬 개발

프록시 구성을 다운로드하여 로컬 컴퓨터에서 수정할 수 있습니다. 작업이 완료되면 결과를 Edge에 업로드합니다. 이 접근 방식을 사용하면 프록시 구성을 소스 제어, 버전 관리, 기타 공유 워크플로에 통합할 수 있습니다. 또한 로컬에서 프록시 구성을 작업하면 자체 XML 편집기와 유효성 검사 도구를 사용할 수 있습니다.

이 섹션에서는 UI를 사용하여 기존 프록시 구성을 다운로드하고 수정한 후 배포를 위해 Edge에 다시 업로드하는 방법을 설명합니다. 또한 apigeetool을 사용하여 새 프록시 구성을 다운로드하고 배포할 수 있습니다(각각 fetchproxy 및 deployproxy 명령어 사용).

UI를 사용하여 로컬로 프록시 구성을 수정하려면 다음 절차를 따르세요.

1. Edge UI에서 현재 프록시 구성을 다운로드합니다. API 프록시 보기에서 프로젝트 > 버전 다운로드를 선택합니다.
2. 로컬 머신에서 새 디렉터리를 만들고 다운로드한 ZIP 파일을 해당 디렉터리로 확장합니다.

   ZIP 파일의 압축을 풀려면 다음 예시와 같이 unzip 등의 유틸리티를 사용할 수 있습니다.

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

   ZIP 파일의 압축을 푼 콘텐츠는 API 프록시 구조에 설명된 구조와 유사합니다.

3. 필요에 따라 소스 파일을 수정합니다. 프록시 구성의 소스 파일에 대한 설명은 API 프록시의 구성 파일 및 디렉터리 구조를 참고하세요.

   예를 들어 API 프록시에서 상태 모니터링을 사용 설정하려면 /apiproxy/targets/ 디렉터리에서 TargetEndpoint 구성 파일을 수정합니다. 이 디렉터리의 기본 파일은 default.xml이지만 조건부 타겟을 사용하는 경우 이름이 다른 파일이 있을 수 있습니다.

   이 경우 TargetEndpoint 구성 파일 및 디렉터리가 없으면 새로 만드세요.

4. 프록시 구성 파일 수정을 마친 후에는 변경사항을 저장해야 합니다.
5. ZIP 파일을 펼칠 때 만든 새 디렉터리로 변경합니다 (확장된 구성 파일의 루트).

   예를 들어 파일의 압축을 /myappdir 디렉터리에 푼 경우 다음 예시와 같이 해당 디렉터리로 변경합니다.

   cd myappdir

   /myappdir 디렉터리는 ZIP 파일에 포함하지 않는 것이 좋으므로 프록시 구성 파일을 다시 보관처리하기 전에 이 디렉터리로 변경해야 합니다. ZIP 파일의 최상위 디렉터리는 /apiproxy이어야 합니다.

6. 새 파일 또는 변경된 파일을 포함하여 프록시 구성 파일을 다시 보관처리합니다. 다음 예에 표시된 것처럼 zip와 같은 유틸리티를 사용할 수 있습니다.

   zip my-new-proxy.zip -r .

   ZIP 파일의 최상위 디렉터리는 /apiproxy이어야 합니다.

   ZIP 파일 이름에는 특별한 요구사항이 없습니다. 예를 들어 버전 번호를 늘리거나 파일 이름에 날짜를 지정할 필요는 없지만 이 작업을 수행하면 디버깅 또는 소스 제어에 유용할 수 있습니다.

   Edge는 새 프록시 구성을 업로드할 때 새 프록시 구성의 버전 번호를 증가시킵니다.

7. Edge UI를 사용하여 새 프록시 구성을 업로드합니다. API 프록시 보기에서 프로젝트 > 새 버전 업로드를 선택합니다.

   Bundle is invalid. Empty bundle. 같은 오류가 발생하면 ZIP 파일의 최상위 디렉터리가 /apiproxy인지 확인합니다. 그렇지 않은 경우 확장 디렉터리의 루트에서 프록시 구성 파일을 다시 보관처리합니다.

   새 프록시 구성을 업로드하면 Edge에서 버전 번호를 증가시켜 버전 요약 뷰에 표시합니다.

   UI를 사용하여 새 버전을 업로드한 후에는 Edge에서 새 버전을 배포하지 않습니다.

8. 새 버전을 배포합니다.

자세한 내용은 Apigee 커뮤니티의 튜토리얼: UI 및 관리 API를 사용하여 프록시를 다운로드하는 방법을 참조하세요.

API 프록시 구조

API 프록시는 다음 구성으로 이루어집니다.

API 프록시 디렉터리 구조 및 콘텐츠

위 표의 구성요소는 다음과 같은 디렉터리 구조의 구성 파일에서 정의됩니다.

API 프록시의 구성 파일 및 디렉터리 구조

이 섹션에서는 API 프록시의 구성 파일 및 디렉터리 구조를 설명합니다.

• 기본 구성
• ProxyEndpoint
• TargetEndpoint
  • TLS/SSL TargetEndpoint 구성
• 정책
• 흐름
• 리소스

기본 구성

/apiproxy/weatherapi.xml

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

샘플 구성:

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

기본 구성 요소

ProxyEndpoint

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

/apiproxy/proxies/default.xml

ProxyEndpoint 구성은 API 프록시의 인바운드(클라이언트 연결) 인터페이스를 정의합니다. ProxyEndpoint를 구성할 때 네트워크 구성을 설정하여 클라이언트 애플리케이션('앱')이 프록시된 API를 호출하는 방법을 정의합니다.

다음의 ProxyEndpoint 구성 샘플은 /apiproxy/proxies에 저장됩니다.

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

기본 ProxyEndpoint의 필수 구성 요소는 다음과 같습니다.

ProxyEndpoint 구성 요소

RouteRule 구성 방법

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

조건부 경로

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

조건부 RouteRules는 Apigee Edge의 다른 조건문처럼 작동합니다. 조건 참조 및 변수 참조를 확인하세요.

예를 들어 다음 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 경로

요청 메시지를 TargetEndpoint로 전달할 필요가 없는 시나리오를 지원하려면 null RouteRule을 정의할 수 있습니다. 이 기능은 ProxyEndpoint가 자바스크립트를 사용하여 외부 서비스를 호출하거나 API 서비스의 키/값 저장소 조회로 데이터를 검색하는 등 필요한 모든 처리를 수행할 때 유용합니다.

예를 들어 다음은 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

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

API 프록시에는 TargetEndpoint가 필요하지 않습니다. ProxyEndpoint는 URL을 직접 호출하도록 구성할 수 있습니다. TargetEndpoint가 없는 API 프록시에는 일반적으로 백엔드 서비스를 직접 호출하거나 자바 또는 자바스크립트를 사용하여 서비스를 호출하도록 구성된 ProxyEndpoint가 포함되어 있습니다.

TargetEndpoint 구성

/targets/default.xml

TargetEndpoint는 Apigee Edge에서 다른 서비스 또는 리소스로의 아웃바운드 연결을 정의합니다.

다음은 TargetEndpoint 구성 샘플입니다.

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

TargetEndpoint 구성 요소

TargetEndpoint는 다음 방법 중 한 가지로 대상을 호출할 수 있습니다.

• HTTP(S) 호출을 위한 HTTPTargetConnection
• 프록시와 프록시 간의 로컬 연결을 위한 LocalTargetConnection
• 에지에서 호스팅되는 Node.js 스크립트 호출에 대한 ScriptTarget

이 중 하나만 TargetEndpoint에서 구성합니다.

TLS/SSL TargetEndpoint 구성

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.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

아웃바운드 클라이언트 인증이 사용 설정된 샘플 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 세부정보를 동적으로 설정하여 유연한 런타임 요구사항을 지원할 수도 있습니다. 예를 들어 프록시가 잠재적으로 상이한 두 개의 대상(테스트 대상 및 프로덕션 대상)에 연결하는 경우 API 프록시를 통해 호출 중인 환경을 프로그래매틱 방식으로 감지하고 적절한 키 저장소 및 트러스트 저장소에 대한 참조를 동적으로 설정할 수 있습니다. 다음의 Apigee 커뮤니티 자료에서 이 시나리오를 자세히 설명하고 배포 가능한 API 프록시 예시를 제공합니다. https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html

TargetEndpoint 구성에서 <SSLInfo> 태그가 설정되는 방식에 대한 다음 예시에서는 가령 자바 콜아웃, 자바스크립트 정책, 할당 메시지 정책 등으로 런타임 시에 값을 제공할 수 있습니다. 설정하려는 값이 포함된 메시지 변수를 사용하세요.

변수는 다음 요소에서만 허용됩니다.

<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 인증서가 만료되거나 시스템 구성 변경으로 인해 인증서를 업데이트해야 하는 경우를 고려해야 합니다. Private Cloud용 Edge 설치에서 정적 값을 사용하거나 흐름 변수를 사용하여 TLS/SSL을 구성할 때 메시지 프로세서를 다시 시작해야 할 수도 있습니다.

자세한 내용은 TLS 인증서 업데이트를 참고하세요.

그러나 원하는 경우 키 저장소 또는 트러스트 저장소에 대한 참조를 사용하도록 TargetEndpoint를 구성할 수 있습니다. 참조를 사용하면 메시지 프로세서를 다시 시작하지 않고도 다른 키 저장소 또는 트러스트 저장소를 가리키는 참조를 업데이트하여 TLS/SSL 인증서를 업데이트할 수 있다는 이점이 있습니다.

예를 들어 아래 TargetEndpoint는 키 저장소에 대한 참조를 사용합니다.

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

다음 POST API 호출을 사용하여 keystoreref라는 참조를 만드세요.

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

참조는 키 저장소의 이름과 유형을 지정합니다.

참조를 보려면 다음 GET API 호출을 사용하세요.

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

다른 키 저장소를 가리키도록 나중에 참조를 변경하여 별칭의 이름을 동일하게 하려면 다음 PUT 호출을 사용합니다.

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

대상 부하 분산을 사용하는 TargetEndpoint

TargetEndpoint는 세 개의 부하 분산 알고리즘을 사용하여 명명된 여러 개의 TargetServer에서 부하 분산을 지원합니다.

자세한 안내는 백엔드 서버 간 부하 분산을 참고하세요.

정책

API 프록시의 /policies 디렉터리에는 API 프록시의 흐름에 연결할 수 있는 모든 정책이 포함됩니다.

정책 구성 요소

정책 연결

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

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

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

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

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

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

정책 연결 구성 요소

흐름

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

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

또한 PostClientFlow를 ProxyEndpoint에 추가할 수 있으며 그러면 요청 측 클라이언트 앱에 응답이 반환된 후에 ProxyEndpointFlow가 실행됩니다. 이 흐름에는 MessageLogging 정책 및 Google Stackdriver Logging 확장 프로그램만 연결할 수 있습니다. 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 프록시는 엔드포인트 구성에서 나타나는 위치와 관계없이 항상 파이프라인의 적절한 지점에서 실행됩니다.

조건부 흐름

ProxyEndpoint 및 TargetEndpoint는 제한된 수의 조건부 흐름('명명된 흐름'이라고도 함)을 지원합니다.

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 Edge에 의해 적용됩니다. 조건부 흐름은 하향식으로 실행됩니다. 조건이 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 변환입니다. 이는 관리 UI에서 API 프록시 편집기의 '스크립트' 섹션에 표시됩니다.

지원되는 리소스 유형은 리소스 파일을 참고하세요.

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

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