목차
API란
API는 Applicatoin Programming Interface의 약자로서, 서로 다른 프로그램(애플리케이션)이 정해진 방식으로 소통할 수 있도록 제공되는 규칙 또는 인터페이스이다.
API의 사용 예시로는 맛집 검색, 지도 확대/축소, 로그인 기능, 날씨정보 조회 등이 있다.
API는 왜 사용하는가?
실무에서는 여러명의 개발자가 하나의 시스템을 개발하는 경우가 많다.
이런 경우에, 개발자들이 서로 코드작성하는 스타일이 다를수도 있고, 신입이나 이적자와 같은 새로운 동료가 유입될경우에 코드를 이해하기 힘들수 있다.
API를 사용하면 내부 구현을 숨긴 채 기능만 제공할 수 있으므로, 새로운 개발자가 합류하더라도 협업이 수비고 유지보수도 간단하다.
웹 API도 이와 동일하다. 클라이언트가 서버에게 요청(Request)을하면, 서버는 이에 대한 응답(Response)를 돌려준다.
여기서 클라이언트는 서버가 무슨 동작을하는지 알 필요 없이, 필요한 기능과 결과만 전달받으면 된다.
즉 API는 작동하는 것을 넘어, 이해하기 편하게 설계하는 것이 중요하다.
REST API란
찜 목록 추가 라는 기능에 대해 개발자 A, B가 서로 개발을 한다 가정한다.
여기서 개발자 A는 이를 POST /createItem으로 구현했고, 개발자 B는 POST /item/new 라고 구현하였다.
둘 다 기능은 정상적으로 동작하지만, API를 사용하는 프론트엔드 개발자의 입장에서는 어떤 API가 어떤 역할을 하는지 예측하기 힘들다.
이러한 혼란을 줄이기 위해 일정한 규칙으로 설계하는 방식을 만들었는데, 그것이 바로 REST(REpresentational State Transfer이다.
REpresentation(표현)은 서버의 자원을 클라이언트가 이해할 수 있는 형태로 표현하는것이다.
JSON, HTML, 이미지 등의 형태가 이에 속한다.
State(상태)는 자원의 현재 상태를 의미하는 것이다.
예를 들어 위의 찜 목록 추가라는 자원에 대해 아이템명, 카테고리, 가격 등의 데이터가 현재 상태가 될 수 있다.
마지막으로, Transfer(전송)은 클라이언트와 서버가 서로 자원의 상태를 주고받는 것을 의미한다.
주로 HTTP통신을 사용한다.
REST 6가지 원칙
-
균일한 인터페이스 (Uniform Interface)
1)자원식별 모든 자원은 고유한 주소로 식별되어야한다. 2)표현을 통한 자원 조작 클라이언트는 `JSON`같은 표현을 가지고 서버의 자원을 조작(조회/등록/수정/삭제) 할 수 있어야한다. 3)자기 서술적 페이지 요청/응답 메시지는 스스로 설명 가능해야한다. Content-Type:application/json이나 Status Code: 201 Created가 예시이다. -
클라이언트-서버(Client-Server) 역할분리
클라이언트는 결과만, 서버는 과정과 데이터만 책임져야한다. -
무상태성(Stateless)
이전에 설명한 HTTP의
무상태성과 같이, 서버는 클라이언트를 기억하지 않는것을 의미한다.
-
주문형 코드(Code-On-Demand)
서버가 데이터 뿐 아니라 실행 가능한 코드를 클라이언트에 전송하여 클라이언트의 기능을 일시적으로 확장시킬 수 있음을 의미한다. 클라이언트는 모든 기능을 내장할 필요 없이, 필요할때만 서버로부터 기능을 다운받아 실행하면 된다. -
캐시 가능(Cacheable)
서버는 응답(Response)을 보낼때, 데이터를 캐시(임시 저장)해도 되는지를 명시하여야 한다.
이는 자주 사용하는 데이터를 임시저장하여 재사용하므로 속도를 높이고 서버 부담을 줄인다.
-
계층형 시스템(Layered System)
클라이언트는 서버가 어떻게 이루어져 있는지를 알 필요 없이 전달한다. 이는 서버가 보안, 성능 등을 위해 중간에 여러 계층을 추가해도 클라이언트에게는 영향이 없다.
