단어 정리

1장. 클라우드 컴퓨팅과 API의 역할 ~ 3장. 클라우드를 제어하는 API의 동작 방식

엔드포인트와 도메인

• 클라이언트는 IP 주소가 아닌 도메인으로 접속하게 된다.
• 엔드포인트를 도메인으로 사용하는 이유는 사람이 알아보기 쉽고, 사용자로부터 IP 주소를 은폐할 수 있기 떄문이다.
• 만약 IP 주소가 변경되거나 웹 API의 엔드포인트로 대량의 요청이 들어오면 가용성을 확보하기 위해 부하를 분산해야 하는데, 이때 API의 엔드포인트를 IP 주소로 공개ㅣ해 두었다면 IP 주소를 바꾸는 것 자체가 어렵다. 클라우드 이용자는 향후 바뀔 IP 주소가 무엇인지 알 방법이 없고, IP 주소가 바뀐 이후에는 접속조차 할 수 없어 클라우드를 제어할 수 없다.
• 도메인은 그대로 두고 매핑할 IP 주소 정보만 갱신할 수 있기 때문에 클라우드 사용자가 서비스를 사용하지 못하게 되는 불상사를 피할 수 있다.
• 서비스 요청이 폭주하여 API 호출이 대량으로 발생하는 상황에서도 리소스의 대수를 늘리도록 스케일 아웃으로 대응할 수 있고, 반대로 사용량이 줄어들 때도 가용한 리소스를 다른 용도로 돌려 쓸 수 있다. DNS의 라운드 로빈 방식이나 가상 호스트 방식을 사용하여 **FQDN과 IP 주소를 1:N 이나 N:1로 매핑 관계를 바꿔주면** 엔드포인트를 수정하지 않더라도 환경적인 변화에 유연하게 대응할 수 있다.

엔드포인트의 경로 설계와 버전 구분

리소스의 지정 방법

API를 호출하는 URL에는 리소스를 식별할 수 있는 정보를 추가해야 하는데, 주로 REST API 방식과 쿼리 API 방식 두 가지 방법을 사용한다.

• REST API : 계층화된 경로 정보로 리소스를 식별하는 방법
  • 리소스의 관계 정보를 URL의 경로에 계층 형태로 표현하는 방법
  • <endpoint>/…/<bucket-name>/<object-name>
• 쿼리 API : 액션에 해당하는 API를 호출할 때 옵션을 추가로 줄 수 있는데 이 옵션들은 URL의 쿼리 파라미터 형태로 사용된다.
  • 리소스 정보는 이 파라미터로 전달하게 된다.
  • <endpoint>/…/?Action=***&ID=*****

액션과 HTTP

웹 API는 호출 시 HTTP 통신을 사용하며, HTTP는 OSI 참조 모델의 7계층(애플리케이션 계층) 프로토콜이다. 하지만 실제 접속은 그 하위의 4계층인 TCP 계층에서 이루어진다. 요청할 때마다 매번 접속을 맺고 끊기 때문에 지속적인 통신에 부담이 생길 수 있다. 이런 경우 "킵얼라이브(Keep-Alive)"라는 기능을 활용할 수 있는데, 이 기능은 한 번 연결된 TCP 접속을 명시적으로 끊으라는 지시가 있기 전까지 계속 유지한다. HTTP 1.1 버전에서는 이 기능이 기본적으로 활성화 되어있다.

HTTP 요청

HTTP 요청은 요청 행, 요청 헤더, 메시지 바디로 이루어져 있다.

HTTP 응답