API Gateway REST 대 HTTP API: 차이점은 무엇입니까?

동일한 기술의 이 두 가지 버전은 어떻게 다릅니까? REST 또는 HTTP API가 최고의 투자인지에 대한 간략한 설명입니다.

V1 대 V2: 심한 충격 피하기

AWS는 REST API를 지원하는 API Gateway의 첫 번째 버전을 2015년에 출시했습니다. 향후 몇 년 동안 AWS는 REST API 지원에 수많은 기능을 추가했습니다 . 여기에는 Cognito 사용자 풀을 통한 인증 지원, VpcLink를 통한 비공개 API 공개 노출, 카나리아 배포 지원 등이 포함됩니다.

그런 다음 2019년에 AWS는 고객 피드백을 기반으로 API Gateway의 새 버전을 개발 했다고 발표했습니다 . 이 V2 버전에는 "HTTP API"(효과적으로 REST API)와 WebSocket API 에 대한 지원이 포함되었습니다 . AWS는 변경의 주요 목표가 API 게이트웨이 모델을 단순화하고 새로운 API를 더 쉽게 개발 및 배포할 수 있도록 하는 것이라고 말했습니다.

그러나 Amazon은 이 "새로운" API 게이트웨이로 많은 혼란을 일으켰습니다. 먼저, "HTTP API"는 REST가 HTTP 프로토콜 위에 구축된 프레임워크임을 감안할 때 이상한 이름입니다 . AWS가 정반대의 소리처럼 들리게 하는 명명 규칙을 선택한 이유를 이해하지 못했습니다.

둘째, 이름은 이들이 동일한 기술의 두 가지 개별 버전이라는 것을 모호하게 만듭니다. 이것은 다음 두 곳 중 한 곳을 볼 때만 분명해집니다.

• REST API 및 HTTP API 구문에 별도의 네임스페이스가 있는 CloudFormation 구문(AWS::ApiGateway 및 AWS::ApiGatewayV2).
• REST API와 HTTP API를 생성하면 완전히 별개의 두 가지 사용자 경험이 제공되는 AWS 콘솔.

위는 REST API(첫 번째 이미지) 및 HTTP API(두 번째 이미지) 사용자 인터페이스의 스크린샷입니다. 보시다시피 V1과 V2 사이에는 상당한 변화가 있습니다. 변경 사항은 UI 구성뿐만 아니라 사용 가능한 기능, 심지어 각 시스템의 가격과 성능까지 확장됩니다.

즉, 어떤 버전의 API Gateway를 사용할지 결정하기 전에 V1과 V2의 차이점을 자세히 이해해야 합니다. 그리고 웹에서 정보를 조사할 때 읽고 있는 기능이 REST API, HTTP API 또는 둘 다에서 지원되는지 여부를 주의 깊게 확인하십시오.

성능 및 가격 차이

REST API와 HTTP API의 주요 차이점은 성능과 가격입니다. 간단히 말해서 HTTP API는 두 가지 모두에서 승자입니다.

REST API와 HTTP API 모두 실제로 이루어진 요청 수와 AWS에서 전송된 데이터에 대해서만 요금을 부과합니다. 다만 가격차이가 심하다. REST API는 요청 100만 건당 미화 3.50달러와 데이터 전송 요금을 실행합니다. 이와 대조적으로 HTTP API는 처음 백만 요청에 대해 요청당 1.00달러, 그 이후에는 백만 요청당 0.90달러의 비용이 듭니다. 무려 71%나 되는 가격 차이입니다.

게다가 AWS는 V2 HTTP API가 V1 REST 형제에 비해 상당한 성능 향상을 포함하고 있다고 말합니다. Cloudonaut의 Andreas Wittig는 몇 가지 수치 를 실행한 결과 REST API에 비해 HTTP API의 지연 시간이 14~16% 개선되었음을 발견했습니다.

Andreas가 지적했듯이 대기 시간 차이는 그리 크지 않습니다. 그리고 데이터베이스와 같은 다른 구성 요소에 대한 종속성으로 인해 대부분이 사라질 가능성이 있습니다. 따라서 HTTP API는 가격면에서 확실한 승자이고 성능면에서는 작은 승자입니다.

REST API의 기능(HTTP API는 아님)

따라서 HTTP API는 가격 책정에 있어 확실한 승자입니다. 하지만 앞서 언급했듯이 가격이 전부는 아닙니다. 그에 대한 대가로 무언가를 얻는다면 더 높은 비용을 정당화할 수 있습니다.

REST API와 HTTP API에는 모두 다른 API에는 없는 기능이 있습니다. HTTP API에 없는 REST API의 기능부터 시작하여 각각을 살펴보겠습니다.

카나리아 지원

사실 이 기사를 쓰게 된 동기 는 카나리아 지원으로 API 게이트웨이 배포 를 구축하고 싶었기 때문 입니다. API Gateway가 카나리아를 지원한다고 들었습니다. 저는 API Gateway와 그 기능의 열렬한 팬이기 때문에 코딩에 뛰어들었습니다.

불행히도 내가 만들기 시작한 것은 HTTP API였습니다. HTTP API가 카나리아 배포를 지원하지 않는다는 사실을 깨달았을 때의 충격과 실망을 상상해 보십시오! 이것은 엄격히 V2에 없는 REST API의 기능입니다.

한 가지 해결 방법은 Application Load Balancer를 아키텍처에 통합하는 것입니다. ALB는 또한 가중치 라우팅을 지원하므로 카나리아 스타일 배포를 구현할 수 있습니다. API Gateway와 함께 ALB를 사용하는 것은 프라이빗 서브넷에서 ALB를 호스팅할 수 있으므로 추가 보안을 제공하는 확립된 패턴입니다 . 그런 다음 API Gateway의 프라이빗 통합 및 VPC 링크를 사용하여 이 프라이빗 서브넷의 엔드포인트로 API 요청을 라우팅할 수 있습니다.

이 패턴은 Docker 컨테이너의 인터넷 노출을 제한하는 추가 이점을 제공합니다. 프라이빗 서브넷에서 컨테이너를 완전히 호스팅하고 공개적으로 사용할 수 있도록 하려는 REST 엔드포인트만 노출할 수 있습니다. 이 패턴 구현에 대한 자세한 내용 은 즉시 사용 가능한 CloudFormation 템플릿과 함께 제공되는 AWS 웹 사이트의 이 문서를 참조하십시오 .

또 다른 해결 방법은 Route 53의 가중치 기반 라우팅 기능을 사용하는 것입니다. ( AWS는 블루/그린 배포의 맥락에서 이 작업을 수행하는 방법에 대한 문서를 보유하고 있습니다.) 이 경우 canaryAPI 게이트웨이에서 다른 단계(예: )를 생성합니다. 그런 다음 가중치 라우팅을 사용하여 트래픽의 일정 비율을 카나리아 단계로 라우팅하고 새 버전의 성능을 확인하면서 트래픽을 점차적으로 이동합니다. 이것은 작동하지만 DNS 전파 지연으로 인해 롤아웃이 느려질 수 있습니다.

WAF(웹 애플리케이션 방화벽) 지원

AWS의 WAF 는 웹 앱에 대한 추가 수준의 보안을 제공합니다. WAF를 사용하면 봇과 알려진 익스플로잇 벡터를 필터링하는 사전 제작 및 사용자 지정 트래픽 보안 규칙을 모두 적용할 수 있습니다. WAF는 애플리케이션의 보안을 강화할 뿐만 아니라 불법적인 대역폭 낭비 트래픽을 줄일 수 있습니다.

API 게이트웨이는 WAF를 지원합니다. 즉, REST API를 사용하는 경우입니다. HTTP API는 현재 WAF를 지원하지 않으며 언제 지원하는지 알 수 없습니다.

위에서 언급한 아키텍처를 사용하는 경우 프라이빗 Application Load Balancer에서 WAF를 켜서 이 문제를 해결할 수 있습니다. ALB는 WAF를 지원합니다. 즉, HTTP API의 더 낮은 비용과 더 높은 성능을 계속 즐기면서 WAF의 이점을 얻을 수 있습니다.

AWS X-Ray 지원

X-Ray는 추적 및 디버깅 도구를 코드에 추가하는 AWS 서비스입니다. X-Ray를 사용하면 코드 및 서비스 성능을 모니터링하고 오류를 보고하며 호출자에게 영향을 미치는 문제의 근본 원인을 해결할 수 있습니다.

REST API에는 API Gateway 호출 에 X-Ray를 추가하기 위한 체크 버튼 지원이 있습니다. 슬프게도 이 글을 쓰는 시점에서 이 기능은 HTTP API에 존재하지 않습니다.

집에서 만든 하나의 추적 옵션이나 New Relic 과 같은 상업용 옵션을 사용하는 팀의 경우 이것은 큰 문제가 아닙니다. 그리고 다른 사람들은 프로그래밍 언어의 AWS SDK 또는 AWS CLI를 통해 코드에서 직접 X-Ray를 사용할 수 있습니다. 따라서 이것이 있으면 좋은 것이지만 반드시 거래 차단기는 아닙니다.

REST API의 기능(HTTP API는 아님)

더 나은 프로그래밍 방식 모델

프로그래밍 방식 모델은 HTTP API가 빛나는 영역 중 하나입니다. HTTP API를 만들 때 AWS가 공언한 동기 중 하나는 REST API가 너무 복잡하다는 것이었습니다. HTTP API는 콘솔에서 간소화된 프로그래밍 모델과 새롭고 향상된 사용자 인터페이스를 사용합니다.

또한 HTTP API는 CORS 구성, 자동 배포, 기본 단계 및 경로에 대한 직접 지원을 포함하여 REST API가 지원하지 않는 여러 가지 사용 편의성 개발 기능을 지원합니다. 그러나 REST API는 요청 본문 변환과 같은 몇 가지 개발 기능을 지원하지만 HTTP API에서 이 글을 쓰는 시점에서 직접 지원되지 않습니다.

그러나 REST API는 Swagger 및 기타 API 정의/문서 도구에서 지원하는 OpenAPI 정의 에서 API 정의 가져오기를 지원하는 한 가지 중요한 방식으로 개발을 더 쉽게 만듭니다 . HTTP API는 OpenAPI로만 내보낼 수 있습니다.

비공개 통합

프라이빗 통합을 통해 API Gateway는 프라이빗 VPC에서 호스팅되는 리소스를 노출할 수 있습니다. 프라이빗 통합을 사용하면 프라이빗 서브넷 내에서 API 소스(예: Docker 컨테이너)를 호스팅하면서 API Gateway를 통해 공개적으로 노출하려는 엔드포인트만 노출할 수 있습니다. 그 결과 보안이 강화됩니다.

HTTP API에는 Application Load Balancer, Network Load Balancer 및 AWS Cloud Map에 대한 완전한 지원이 포함되어 있습니다. API 게이트웨이에서 프라이빗 서브넷으로의 경로를 생성할 수 있는 VPC 링크를 통해 지원이 활성화됩니다. VPC 링크는 콘솔과 CloudFormation 모두에서 쉽게 구성하고 할당할 수 있습니다. ( 여기에서 작동하는 CloudFormation 예제를 찾을 수 있습니다 .)

REST API는 Network Load Balancer만 지원합니다. 또한 구성이 VPC Link의 경우만큼 간단하지 않습니다.

비공개 통합은 비공개 API 와 혼동되어서는 안 됩니다 . 프라이빗 API를 사용하면 API Gateway를 사용하여 VPC를 통해서만 사용할 수 있는 API를 정의할 수 있습니다. API에 대한 호출은 VPC 내에 유지되며 공용 인터넷을 통해 라우팅되지 않습니다. REST API만 프라이빗 API를 지원합니다.

네이티브 OpenID Connect / OAuth 2.0

마지막으로 HTTP API는 OpenID Connect 및 OAuth 2.0을 기본적으로 지원합니다. 이것은 REST API가 기본적으로 지원하지 않는 인증 프레임워크입니다.

REST API에서 고유한 OAuth 2.0 지원을 구현하는 것은 확실히 가능 합니다 . 그러나 이것은 HTTP API의 기본 지원을 사용하는 것보다 더 무거운 리프트입니다.

어느 것을 사용할 것인가?

여기에서 다루지 않은 몇 가지 다른 기능 차이점이 있습니다. 문서를 숙지하고 다른 것을 선택하여 얻을 수 있는 것과 놓칠 수 있는 것을 확인하는 것이 가장 좋습니다. 일을 더 쉽게 하기 위해 다음은 표 형식으로 된 간단한 요약입니다.

보시다시피, HTTP API는 기능 지원 측면에서 따라잡아야 합니다. 반면에 HTTP API는 훨씬 더 경제적이고 성능이 좋으며 사용하기 쉽습니다.

제 생각에는 REST API가 관리를 더 쉽게 만들고 출시 시간을 단축하는 몇 가지 중요한 기능을 선택하는 경우 REST API를 사용하도록 선택할 수 있습니다(예: OpenAPI 가져오기). 그러나 HTTP API의 전반적인 개선으로 인해 대부분의 프로젝트에서 기본적으로 선택됩니다. 큰 노력 없이 REST API 고유의 대부분의 기능을 직접 구현할 수 있습니다. 또한 AWS가 이 새로운 서비스에 계속 투자함에 따라 향후 사용성, 가격 및 성능 개선의 이점을 얻을 수 있습니다.

출처 : https://blog.tinystacks.com/aws-api-gateway-rest-http