최근 기술면접에서 REST API를 질문받은 적이 있었다. 아마 대답을 했던 것 같은데, 완벽한 대답이었다고는 생각하지 않는다. 보통 백엔드 개발자라면 API를 개발하는 업무를 수행하고, 이 때 REST API혹은 RESTful API 아키텍처 형태로 개발할텐데 이에 대해서 정확히 알고 있지 못하는 것 같다. 따라서 본 포스팅을 통하여 REST API에 대해 자세히 정리를 하고 추후 API 설계를 할 때 도움을 받고자 한다.
REST란 REpresentational State Transfer의 약자이다. REST는 프로토콜이나 표준이 아니라 아키텍처 원칙 세트인데, 따라서 REST API는 REST 아키텍처를 따르는 조건을 만족하여야 한다.
1. 클라이언트-서버 구조
2. 무상태성이어야 할 것
3. 캐시가 가능할 것
4. 표준 형식으로 전송되기 위한 통합 인터페이스
- 리소스가 URI로 식별될 것
- 클라이언트가 수신한 정보를 바탕으로 리소스의 생성, 수정, 삭제등이 가능해야 함
- 클라이언트에 반환하는 self-descriptive 메세지에 정보를 어떻게 처리할 지에 대한 정보가 포함되어야 함
- 애플리케이션의 상태는 하이퍼링크를 사용하여 상태 전이가 되어야 함.
5. 계층화된 구조
- 보안, 로드 밸런싱 등을 위하여 계층적인 구조로 체계화되는 계층화된 시스템
6. 코드 온디맨드(optional)
- 요청에 의하여 서버에서 클라이언트로 실행 가능한 코드를 전송할 수 있음(예를 들어서 자바스크립트 코드)
아마 HTTP API를 따른다면 클라이언트-서버 구조, 무상태성, 캐시가능, 계층화된 구조를 가져야 하므로 REST API 조건을 따르면 HTTP API라고 할 수 있을 것이다. 또한 REST API 아키텍처 조건 중 통합 인터페이스 항목에서 3, 4번은 지켜지기가 힘들다고 한다. 아래는 3,4번에 대한 예제인데, 대부분의 개발자들도 3, 4번 항목을 무시하고 코드를 작성한다고 한다(필자도 포함된다). 따라서 보통 REST API라고 하면 HTTP API를 생각하는 것이 좋을 수도 있다.
HTTP API 및 URI 설계는 이전 포스트를 참고부탁드립니다!
HTTP/1.1 200 OK
[{"name":"kimjy", "nickname":"kimjy"}]- self-descriptive 메세지에 정보를 어떻게 처리할 지에 대한 정보가 없음
- name이 무엇을 의미하는 지, nickname이 무엇을 의미하는 지 정보가 전달되지 않음.
HTTP/1.1 200 OK
Content-Type: application/json
Link: </users/1>; rel="previous",
</users/3>; rel="next",
{
"id": "kimjy",
"nickname": "kimjy"
}- Link와 같이 애플리케이션의 상태전이를 위해 users/1과 users/3의 정보가 담겨 있음.