간단한 API 프록시 빌드

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

Apigee를 사용하면 백엔드 서비스를 API로 빠르게 노출할 수 있습니다. 이렇게 하려면 노출하려는 백엔드 서비스의 퍼사드를 제공하는 API 프록시를 만듭니다. 백엔드 서비스의 네트워크 주소만 제공하고 개발자에게 노출되는 API 프록시를 만드는 데 Apigee가 사용하는 일부 정보를 제공해야 합니다.

API 프록시는 개발자가 사용하는 API에서 백엔드 서비스 구현을 분리합니다. 이렇게 하면 개발자가 향후 백엔드 서비스를 변경하는 것을 방지할 수 있습니다. 백엔드 서비스를 업데이트할 때 개발자는 이러한 변경사항에서 격리되어 API를 중단 없이 계속 호출할 수 있습니다.

이 주제에서는 여러 프록시 유형과 이에 대한 설정에 대한 정보를 제공합니다. 프록시 만들기에 대한 단계별 안내는 다음 항목을 참조하세요.

튜토리얼: 첫 번째 API 프록시 빌드
API 프록시 만들기

UI를 사용하여 API 프록시 만들기

API 프록시를 만드는 가장 쉬운 방법은 프록시 만들기 마법사를 사용하는 것입니다.

Apigee UI를 사용하여 프록시 만들기 마법사에 액세스하려면 다음 단계를 수행합니다.

Apigee UI에 로그인합니다.
탐색 메뉴에서 개발 > API 프록시를 선택합니다.
새로 만들기를 클릭합니다.

프록시 만들기 마법사는 API 프록시에 최소한의 기능을 생성하고 추가하는 단계를 보여주고 안내합니다.

프록시 만들기 마법사의 첫 번째 페이지는 마법사 흐름을 맞춤설정하기 위해 역방향 프록시, 대상 없음, 또는 프록시 번들을 선택하라는 메시지가 표시됩니다.

마법사의 첫 번째 페이지를 통해 다음 소스로부터 API 프록시를 만들 수 있습니다.

유형	설명
역방향 프록시(가장 일반적)	인바운드 요청을 기존 HTTP 백엔드 서비스로 라우팅하는 API 프록시입니다. JSON 또는 XML API일 수 있습니다. 이 섹션의 뒷부분에 나오는 HTTP 서비스용 역방향 프록시 만들기를 참조하세요. OpenAPI 사양 사용을 클릭하여 유효한 OpenAPI 사양에서 프록시를 생성합니다. 이 옵션에 대한 자세한 내용은 이 섹션의 뒷부분에 있는 OpenAPI 사양을 사용하여 프록시 생성을 참조하세요.
대상 없음	API 백엔드가 없는 API 프록시('no target')입니다. API 프록시 세부정보를 정의할 때 기존 API를 지정하지 않는다는 점을 제외하면 앞에서 설명한 HTTP 서비스용 역방향 프록시 생성과 유사합니다. OpenAPI 사양 사용을 클릭하여 유효한 OpenAPI 사양에서 프록시를 생성합니다. 이 옵션에 대한 자세한 내용은 이 섹션의 뒷부분에 있는 OpenAPI 사양을 사용하여 프록시 생성을 참조하세요.
프록시 번들 업로드	기존 API 프록시 번들(예를 들어 GitHub에서 사용할 수 있는 샘플 API 프록시 중 하나)입니다. API 프록시 번들에서 API 프록시 가져오기를 참고하세요.

유형

설명

역방향 프록시(가장 일반적)

인바운드 요청을 기존 HTTP 백엔드 서비스로 라우팅하는 API 프록시입니다. JSON 또는 XML API일 수 있습니다. 이 섹션의 뒷부분에 나오는 HTTP 서비스용 역방향 프록시 만들기를 참조하세요.

OpenAPI 사양 사용을 클릭하여 유효한 OpenAPI 사양에서 프록시를 생성합니다. 이 옵션에 대한 자세한 내용은 이 섹션의 뒷부분에 있는 OpenAPI 사양을 사용하여 프록시 생성을 참조하세요.

대상 없음

API 백엔드가 없는 API 프록시('no target')입니다. API 프록시 세부정보를 정의할 때 기존 API를 지정하지 않는다는 점을 제외하면 앞에서 설명한 HTTP 서비스용 역방향 프록시 생성과 유사합니다.

프록시 번들 업로드

기존 API 프록시 번들(예를 들어 GitHub에서 사용할 수 있는 샘플 API 프록시 중 하나)입니다. API 프록시 번들에서 API 프록시 가져오기를 참고하세요.

다음 섹션에서는 각 프록시 유형을 자세히 다룹니다.

HTTP 서비스용 역방향 프록시 만들기

Apigee는 다음 정보를 기준으로 역방향 프록시를 생성합니다.

백엔드 서비스의 URL
API 프록시에서 소비자 앱에 노출되는 API를 고유하게 식별하는 URI 경로입니다.

백엔드 서비스 URL은 일반적으로 조직에서 소유한 서비스 사용 설정 애플리케이션을 나타냅니다. 공개적으로 사용 가능한 API를 가리킬 수도 있습니다. API 또는 서비스는 제어할 수 있거나(예: 내부 HR 애플리케이션 또는 Cloud의 Rails 애플리케이션) 타사 API 또는 서비스(예: Twitter 또는 Instagram)일 수 있습니다.

다음 프록시 세부정보는 프록시 만들기 마법사에 액세스하여 프록시 유형을 선택한 후에 사용할 수 있습니다.

필드	설명
이름	API에 표시되는 이름입니다. 영숫자 문자, 대시(-) 또는 밑줄 (_)을 사용하여 지정하세요.
기본 경로	API 프록시의 `http://[host]` 또는 `https://[host]` 주소 뒤에 표시되는 URI 프래그먼트입니다. Apigee는 기본 경로 URI를 사용하여 수신되는 요청 메시지를 적절한 API 프록시에 일치시키고 라우팅합니다. 참고: API 프록시 기본 경로는 기본적으로 모든 소문자로 변환된 `Name` 필드에 대해 지정된 값으로 설정됩니다. 기본 경로 뒤에는 추가 리소스 URL이 있습니다. 클라이언트가 API 프록시를 호출하는 데 사용하는 전체 URL 구조는 다음과 같습니다. `https://[host]/BASE_PATH/CONDITIONAL_FLOW_PATH` 참고: 기본 경로는 고유해야 합니다. 동일한 기본 경로를 가진 2개의 API 프록시를 배포할 수 없습니다. 배포된 API 프록시를 수정하고 기본 API를 다른 API 프록시의 기본 경로와 동일한 값으로 설정하면 Apigee는 저장할 때 자동으로 API 프록시 배포를 취소합니다. API 프록시를 재배포하려면 먼저 기본 경로를 고유한 경로로 수정해야 합니다. 기본 경로에 와일드 카드 사용 API 프록시 기본 경로에서 하나 이상의 `//` 와일드 카드를 사용하여 API 프록시를 향후에 대해 보호합니다. 예를 들어 `/team//members`의 기본 경로를 사용하면 클라이언트가 새 팀을 지원하기 위해 새 API 프록시를 만들 필요 없이 `https://[host]/team/blue/members` 및 `https://[host]/team/green/members`를 호출할 수 있습니다. `/**/`는 지원되지 않습니다.
설명	(선택사항) API에 대한 설명입니다.
대상(기존 API)	이 API 프록시가 호출하는 백엔드 서비스의 URL입니다.

API 프록시 번들에서 API 프록시 가져오기

종종 API 프록시를 다른 지원 파일과 함께XML 파일의 컬렉션으로 정의합니다. API 프록시를 Apigee 외부의 파일 집합으로 정의하면 소스 제어 시스템에서 유지관리한 후 테스트 및 배포를 위해 Apigee로 가져올 수 있습니다.

API 프록시 번들에서 API 프록시를 가져오려면 다음 단계를 수행합니다.

이 섹션의 앞부분에 있는 UI를 사용하여 API 프록시 만들기에 설명된 대로 프록시 만들기 마법사에 액세스합니다.
프록시 번들 업로드를 클릭합니다.

프록시 마법사의 프록시 번들 업로드 페이지에서 다음 정보를 입력합니다.

필드	설명
ZIP 번들	API 프록시 구성이 포함된 ZIP 파일입니다. 드래그 앤 드롭하거나 클릭하여 파일로 이동합니다.
이름	API에 표시되는 이름입니다. 확장자를 제외한 ZIP 파일 이름을 기본값으로 사용합니다.

다음을 클릭합니다.
요약 페이지에서 배포 환경을 선택하고 원하는 경우 만들기 및 배포를 클릭합니다.

새 API 프록시가 성공적으로 생성되었음을 보여주는 확인이 표시됩니다.
프록시 수정을 클릭하여 API 프록시의 세부정보 페이지를 표시합니다.

gRPC API 프록시 만들기

REST API 프록시 외에도 Apigee는 현재만 한정적으로 패스 스루 지원이 포함된 gRPC API 프록시를 지원합니다. 패스 스루 지원을 통해 gRPC 페이로드는 자체적으로 Apigee에 불투명하며, gRPC 클라이언트에서 대상 구성에 사전 구성된 gRPC 대상 서버로 트래픽이 라우팅됩니다.

현재 Apigee gRPC API 프록시는 다음과 같은 특성을 갖습니다.

단항 gRPC 요청을 지원합니다.
페이로드에 영향을 주는 정책을 사용할 수 없습니다.
GraphQL 또는 REST 프록시와 연결되지 않은 API 제품에서 사용할 수 있습니다. API 제품 관련 할당량 및 기타 작업 설정이 제품의 모든 프록시에 적용됩니다.
Apigee Hybrid에서는 지원되지 않습니다.
두 가지 gRPC 관련 흐름 변수인 request.grpc.rpc.name과 request.grpc.service.name이 사용됩니다.
gRPC와 관련된 Apigee 애널리틱스 변수인 x_apigee_grpc_rpc_name, x_apigee_grpc_service_name, x_apigee_grpc_status을 사용하여 모니터링할 수 있습니다.
gRPC 상태 코드를 반환합니다.

또한 gRPC를 지원하도록 부하 분산기를 구성해야 합니다. 애플리케이션에 gRPC 사용 및 gcloud CLI 명령어를 사용하여 gRPC에 대한 라우팅 만들기를 참조하세요.

gRPC API 프록시를 만들려면 먼저 gRPC 대상 서버를 정의하고(대상 서버 만들기 참조) 새 프록시를 만들 때 대상 서버를 지정합니다.

gcloud CLI 명령어를 사용하여 gRPC에 대한 라우팅 만들기

이 섹션에서는 gcloud CLI를 사용해서 gRPC 프록시에 대해 라우팅을 만들기 위한 명령어 예시를 보여줍니다. 여기에는 부하 분산기, 대상 서버, MIG 설정이 포함됩니다.

이 섹션은 라우팅 만들기에 대한 포괄적인 가이드가 아닙니다. 이러한 예시는 일부 사용 사례에 따라 적합하지 않을 수 있습니다. 또한 여기에서는 사용자가 외부 라우팅(MIG) 및 Cloud 부하 분산기 gRPC 구성에 익숙하다고 가정합니다.

환경 변수 설정하기

이러한 환경 변수는 하위 섹션의 명령어에 사용됩니다.

PROJECT_ID=YOUR_PROJECT_ID
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=default
VPC_SUBNET=default
REGION=REGION_NAME
APIGEE_ENDPOINT=ENDPOINT
CERTIFICATE_NAME=CERTIFICATE_NAME
DOMAIN_HOSTNAME=DOMAIN_HOSTNAME

새 부하 분산기를 사용하여 gRPC 프록시에 대해 라우팅을 만들기 위한 gcloud CLI 명령어 예시

이 섹션에서는 gcloud CLI 및 새로운 부하 분산기를 사용해서 gRPC 프록시를 만들기 위한 명령어 예시를 보여줍니다. 여기에는 부하 분산기, 대상 서버, MIG 설정이 포함됩니다.

인스턴스 템플릿 만들기

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

관리형 인스턴스 그룹 만들기

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

자동 확장 구성

gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 50 \
--target-cpu-utilization 0.75 --cool-down-period 90

이름이 지정된 포트 정의

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

부하 분산기의 Google 관리 SSL 인증서와 키 만들기

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

인증서가 프로비저닝되었는지 확인

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

글로벌 Cloud 부하 분산기(GCLB) 만들기

상태 점검 만들기

gcloud compute health-checks create https hc-apigee-envoy-443 \
--project $PROJECT_ID --port 443 --global \
--request-path /healthz/ingress

http1의 백엔드 서비스 만들기

gcloud compute backend-services create YOUR_BACKEND_1 \
--project $PROJECT_ID \
--protocol HTTPS \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

http2의 백엔드 서비스 만들기

gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

백엔드 서비스에 MIG를 추가합니다. 이 예시에서는 MIG를 재사용하지만 새 MIG 쌍을 만들 수도 있습니다.

gcloud compute backend-services add-backend YOUR_BACKEND_1 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

부하 분산 URL 맵을 만듭니다. 먼저 URL 맵이 있는지 확인합니다. 맵이 있으면, 이를 덮어쓰기 보다 아래 요구사항에 따라 해당 맵을 수정합니다.

/tmp/apigee-map.yaml에서 이 구성과 함께 YAML 파일을 만들거나 기존 파일을 사용합니다. URL 맵 http1 백엔드가 기본값입니다.

defaultService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_2
weight: 100

URL 맵을 검증합니다.

gcloud compute url-maps validate --source /tmp/apigee-map.yaml --project $PROJECT_ID

헤더 기반 라우팅을 사용해서 URL 맵을 만듭니다.

gcloud compute url-maps import apigee-http1-http2 \
--source /tmp/apigee-map.yaml  \
--global --project $PROJECT_ID

부하 분산 대상 HTTPS 프록시 만들기

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

IPV4 외부 IP 예약 및 부하 분산기에 대한 방화벽 규칙 만들기

gcloud compute addresses create lb-ipv4-vip-1 \
--project $PROJECT_ID \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global

  gcloud compute addresses describe lb-ipv4-vip-1 \
--project $PROJECT_ID --format="get(address)" --global

  gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \
--project $PROJECT_ID --address lb-ipv4-vip-1 --global \
--target-https-proxy apigee-envoy-https-proxy --ports 443

방화벽 규칙 만들기

gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

기존 부하 분산기에 대해 gRPC 프록시의 라우팅을 만들기 위한 gcloud CLI 명령어 예시

이 섹션에서는 gcloud CLI 및 기존 부하 분산기를 사용하여 gRPC 프록시를 만들기 위한 명령어 예시를 보여줍니다. 여기에는 부하 분산기, 대상 서버, MIG 설정이 포함됩니다.

http2의 다른 백엔드 서비스 만들기

# Create backend service for http2
    gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

MIG에 두 번째 백엔드 서비스 연결

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

기존 Apigee GCLB의 URL 맵 나열

gcloud compute url-maps list -project $PROJECT_ID

Apigee 부하 분산에 사용되는 올바른 URL 맵 이름 선택

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

부하 분산 URL 맵 YAML 파일 만들기

기존 URL 맵이 이미 있으면 이 구성을 여기에 병합합니다. 그렇지 않으면 이 구성을 사용해서 /tmp/apigee-map.yaml에서 YAML을 만듭니다.

defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2
weight: 100

gRPC 라우팅에 새 YAML 적용

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

보안 추가

프록시 만들기 마법사의 일반 정책 페이지에서 추가하려는 보안 승인 유형을 선택합니다. 다음은 사용 가능한 옵션을 요약한 표입니다.

보안 승인	설명
API 키	정의하려는 API 프록시에 간단한 API 키 확인을 추가합니다. 이에 대한 응답으로 API 플랫폼은 VerifyAPIKey 정책과 AssignMessage 정책을 API 프록시에 추가합니다. VerifyAPIKey 정책은 앱을 요청하여 표시되는 API 키의 유효성을 검사합니다. AssignMessage 정책은 백엔드 서버로 전달되는 요청에서 쿼리 매개변수로 API 호출에 제공되는 API 키를 삭제합니다.
OAuth 2.0	API 프록시에 OAuth 2.0 기반 인증을 추가합니다. Apigee는 API 프록시에 두 가지 정책을 자동으로 추가합니다. 하나는 액세스 토큰을 확인하기 위한 정책이고 다른 하나는 백엔드 서비스에 전달하기 전에 메시지에서 액세스 토큰을 삭제하는 정책입니다. 액세스 토큰을 가져오는 방법은 OAuth를 참고하세요.
패스 스루(승인 없음)	승인 필요 없음. Apigee의 보안 확인 없이 백엔드에 요청이 전달됩니다.

CORS 지원 추가

교차 출처 리소스 공유(CORS)는 웹브라우저가 다른 도메인에 직접 요청을 수행할 수 있도록 허용하는 표준 메커니즘입니다. CORS 표준은 웹브라우저와 서버가 교차 도메인 통신을 구현하는 데 사용하는 HTTP 헤더 집합을 정의합니다.

다음 중 하나를 수행하여 CORS에 대한 지원을 추가할 수 있습니다.

ProxyEndpoint의 요청 PreFlow에 CORS 정책 추가
프록시 만들기 마법사의 일반 정책 페이지에서 CORS 헤더 추가 선택

CORS 시행 전 지원 추가 등을 포함한 CORS 지원에 대한 자세한 정보는 API 프록시에 CORS 지원 추가하기를 참고하세요.

할당량 추가

할당량 아래의 높은 트래픽으로부터 백엔드 서비스를 보호하기 위한 할당량입니다. 할당량 부분을 참고하세요. (패스 스루 승인을 선택한 경우에는 사용할 수 없습니다.)

OpenAPI 사양을 사용하여 프록시 생성

이 섹션에서는 OpenAPI 사양에서 역방향 또는 대상 없음과 같은 유형의 API 프록시를 생성하기 위해 사용할 수 있는 OpenAPI 사용 옵션을 설명합니다.

OpenAPI 사양이란 무엇인가요?

Open API Initiative 로고 'Open API Initiative(OAI)는 Swagger 사양에 따라 공급업체 중립적 API 설명 형식을 생성, 발전, 승격하는 데 중점을 두고 있습니다.' 자세한 내용은 OpenAPI Initiative를 참조하세요.

OpenAPI 사양에서는 표준 형식을 사용하여 RESTful API를 설명합니다. JSON 또는 YAML 형식으로 작성된 OpenAPI 사양은 머신이 읽을 수 있지만 사람도 쉽게 읽고 이해할 수 있습니다. 사양은 기본 경로, 경로 및 동사, 헤더, 쿼리 매개변수, 작업, 콘텐츠 유형, 응답 설명 등과 같은 API 요소를 설명합니다. 또한 OpenAPI 사양은 일반적으로 API 문서를 생성하는 데 사용됩니다.

OpenAPI 사양의 다음 프래그먼트는 Apigee의 모의 대상 서비스인 http://mocktarget.apigee.net을 설명합니다. 자세한 내용은 helloworld 샘플에 대한 OpenAPI 사양을 참조하세요.

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

프록시 만들기 마법사를 통해 OpenAPI 사양을 가져오고 이를 사용하여 API 프록시를 생성할 수 있습니다. 프록시가 생성되면 모든 Apigee 프록시처럼 Apigee UI를 사용하여 정책을 추가하고, 커스텀 코드를 구현하는 등의 작업을 통하여 개발할 수 있습니다.

OpenAPI 사양에서 API 프록시 만들기

OpenAPI 사양에서 API 프록시를 만듭니다. 몇 번의 클릭만으로 경로, 매개변수, 조건부 흐름, 대상 엔드포인트가 자동으로 생성된 API 프록시를 갖게 됩니다. 그런 다음 OAuth 보안, 비율 제한, 캐싱과 같은 기능을 추가할 수 있습니다.

프록시 만들기 마법사에서 OpenAPI 사양 사용을 클릭하고 마법사의 지시에 따라 OpenAPI 사양에서 역방향 프록시나 대상 없는 프록시를 만듭니다. 자세한 내용은 OpenAPI 사양에서 API 프록시 만들기를 참조하세요.

API 프록시의 새 버전 만들기

아래에 설명된 대로 API 프록시의 새 버전을 만듭니다.

API 프록시의 새 버전을 만들려면 다음 단계를 수행하세요.

Apigee UI에 로그인합니다.
탐색 메뉴에서 개발 > API 프록시를 선택합니다.
복사하려는 목록에서 API 프록시를 클릭합니다.
개발 탭을 클릭합니다.
저장 버튼을 선택하고 새 버전으로 저장을 선택합니다.

API 프록시 백업

API 프록시 번들에 기존 API 프록시를 XML 파일 집합으로 백업할 수 있습니다. 번들에 내보낸 후에는 이 섹션 앞부분의 API 프록시 번들에서 API 프록시 가져오기에 설명된 대로 API 프록시를 새 프록시로 가져올 수 있습니다. 자세한 내용은 API 프록시 다운로드를 참고하세요.

API를 사용하여 API 프록시 만들기

API를 사용하여 API 프록시를 만들려면 API 프록시 만들기를 참조하세요.