stage 는 같은 API 설정에 대해서 환경을 구분할 때 또는 버전을 구분할 때 쓴다
스테이지에서 내가 생성한 API Gateway 선택하고
Stages에 들어가서 Create stage 클릭
Stage name : v2
Deployment : 이걸 생성한다는 것은 Deployment가 생성된다 라는 것과 같다. 마지막에 Deployment한 것 선택해주면 된다.
추가적인 세팅 하지 않고 Create stage
v2가 만들어진 모습이다.
Invoke URL를 확인해보면
같은 해시의 주소인데 뒤에만 v2로 바뀌었다.
터미널에서 curl로 확인해보면 API가 잘 호출되는 것을 볼 수 있다.
이제 새로운 변경을 줘 보자.
버전을 구분하기 위해서 Integration request 에서 새로운 헤더를 추가해줄 것이다.
Resources 에서
/user 의 GET method 클릭,
Integration request 클릭,
Edit 클릭
Edit integration request 페이지 맨 아래
URL request headers parameters 에서
Add request header parameter 클릭,
Name : X-VERSION
Mapped from :'2'
save 클릭.
(API Gateway를 거쳐가면서 x-version이란 Header key에 2라는 Value를 넣어주겠다는 설정.)
Deploy API 클릭,
Stages value : v2
Deploy 클릭
이제 v2에 배포가 되었다.
그러면 v1과 v2가 어떻게 다른지 User API로 확인해보자.
터미널에서 invokeURL/v1/user 입력
오른쪽 터미널에서 invokeURL/v1/user를 호출하니
왼쪽 상단 1번 서버가 응답하는데 아까랑 다른 게 없는 모습이다.
터미널에서 invokeURL/v2/user 입력
터미널에서 invokeURL/v2/user를 호출해보면
x-version이라는 커스텀 헤더가 포함되어 있고, 해당 헤더의 값으로 2가 설정되어 있는 것을 확인할 수 있다.
이렇게 스테이지를 구분해서 별도의 배포 버전을 가져가는 방법을 실습으로 알아보았다.
API Gateway Stage의 활용: 버전 구분 vs 환경 구분
API Gateway의 Stage는 동일한 API 리소스와 설정을 기반으로 배포 환경 또는 버전을 구분하기 위해 사용하는 기능이다. 실무에서는 주로 다음 두 가지 방식으로 활용된다.
1. 버전 구분 방식 (실습에서 사용)
API 경로에 /v1, /v2와 같이 버전명을 포함시키는 방식이다.
이 방식의 장점
-
클라이언트가 어떤 버전의 API를 사용하는지 명확하게 확인할 수 있다.
-
각 버전별로 독립적인 배포 및 테스트가 가능하다.
-
실습이나 데모 환경에서 사용하기에 적합하다.
예시:
https://api.example.com/v1/user,https://api.example.com/v2/user
2. 환경 구분 방식 (실무에서 주로 사용)
Stage를 alpha, beta, prod 등으로 명명하여 배포 환경 구분에 사용하는 방식이다.
이 방식의 장점
-
동일한 API 리소스를 재사용하면서도 환경별로 분리된 배포가 가능하다.
-
설정을 공유하므로 중복 없이 효율적으로 관리할 수 있다.
-
개발 → 테스트 → 운영 배포 과정의 흐름을 명확하게 관리할 수 있다.
예시:
https://api.example.com/alpha/user,https://api.example.com/prod/user
