
개발을 하다보면 한 번쯤은 "API"라는 것을 들어봤을 것이다. 나도 여태까지 API 요청, API 명세서,, 등등을 말하면서 한 번도 정확히 API가 무엇인가에 대해 제대로 찾아본 적이 없는 것 같아서 이번 기회를 통해 정확히 짚고 넘어가보고자 한다.
API는 Application Programming Interface의 약자로 두 개 혹은 그 이상의 컴퓨터 프로그램이 서로 소통할 수 있게 해주는 매개체 역할을 한다.
예시
쇼핑몰 웹사이트를 방문하면 물건을 구매할 때 발생하는 이벤트, 장바구니에 물건을 추가하는 이벤트, 다음 화면으로 넘어가기 위해 필요한 이벤트 등 다양한 이벤트가 발생한다. 물건 A를 장바구니에 넣는다고 가정한다. AP는 '장바구니에 넣는다'라는 요청을 전달받고, '아! 손님이 장바구니에 넣으려 하는 물건이 A 구나!'라고 생각하며 장바구니에 넣는 작업을 진행하는 서버로 요청을 보낸다. 그리고 서버 측에서 업데이트를 마치면 이 사실을 API에게 전달하고, API는 고객에게 장바구니에 물건 A가 잘 들어간 것을 확인하는 화면을 보여준다. 이때 API 관할 구역이 존재하는데, 이 구역은 쇼핑몰 웹사이트에서 장바구니 추가 기능을 담당하는 곳까지 요청을 전달하고 결과를 받는 영역이다.
API란 중간에서 요청을 받고 요청을 다른 곳으로 보내거나 처리하는 일을 한다. 웹프로그래밍에서 빠질 수 없는 중요한 역할을 한다.
API를 안다면 RESTful API, REST API 또한 들어봤을 것이다. REST는 REpresentational State Transfer의 약자로 상태 변화를 주기 위해 서버와 클라이언트 간 소통하는 데 사용된다. 즉, 두 개 혹은 여러 개의 시스템이 서로 용이한 대화를 할 수 있게 해주는 역할을 담당한다. RESTful API는 무언가를 새로 만들 때(CREATE), 어떤 정보를 불러올 때(READ), 이미 존재하는 데이터를 수정할 때(UPDATE), 마지막으로 존재하는데이터를 삭제할 때(DELETE) 총 네 가지 요청을 사용한다. 네 가지 요청을 줄여 'CRUD'라고 하며, 이는 사용자와 시스템 간 소통을 위해 필요한 최소한의 인터페이스를 의미한다.
RESTful API는 JSON 포맷으로 요청을 전달하며 요청받는 내용 역시 JSON 포맷이다. 다음과 같은 JSON 데이터를 특정 요청에 근거하여 서버로 전송하는데 이를 RESTful API가 담당한다.
RESTful API는 웹사이트 개발 시 서버와 클라이언트를 분리시킬 수 있다. 이를 모델-뷰-컨트롤러(MVC) 패턴이라 하며 클라이언트가 보는 뷰와 서버의 컨트롤러를 독립적으로 개발할 수 있는 유연성을 제공한다.
API Gateway는 뛰어난 확장성을 제공하며 직접 API를 만들고 이를 CloudWatch에서 모니터링하는 기능이 있습니다. 또한 EC2 인스턴스에서 돌아가는 서버 및 웹 애플리케이션에 접근하여 API 기능을 추가할 수 있다.
API Gateway는 페이고 원칙을 따른다. API Gateway를 사용한다고 비용을 지불하는 것이 아니라 서버에서 API 요청을 받을 때 API 요청 처리 시간에 따라 비용을 지불한다. API Gateway는 사용 사례에 따라 API 요청 결과를 다른 목적지로 안전하게 보낼 수 있다. API Gateway는 AWS로부터 추가적인 보안층을 전달받아 DoS 공격, SQL 주입공격 같은 것으로부터 보호를 받는다. API Gateway의 목적지는 크게 네 가지로 생각할 수 있다. 전 세계 모든 사람에게 공개된 API, 특정 사람에게만 접근 가능한 비공개 API, 그밖에 다른 사용 사례를 지닌 API 또는 다른 AWS 리소스로 요청 결과를 전달하는 서비스형 함수(Faas, Function as a serice)다. 이곳으로 안전하게 요청 결과를 보낸다.
Reference
업무에 바로 쓰는 AWS 입문, 김성민