Rest API
Rest는 Representational State Transfer의 약자로, 아키텍처 스타일이다.
아키텍처 스타일은 아키텍처 패턴과 약간 다른 개념이다.
- 아키텍처 패턴
- 어떤 반복되는 문제 상황을 해결하기 위한 도구
- 아키텍처 스타일
- 반복되는 아키텍처 디자인
Rest 아키텍처 스타일은 6가지 제약 조건으로 구성된다.
이 가이드 라인을 따르는 API를 RestFul API 라고 한다.
- Client - Server
- 상태가 없는 Stateless
- 캐시 가능한 데이터
- 일관적인 인터페이스
- 레이어 시스템
- 코드 온-디맨드
Client-Server
Client-Server 라는 것은 리소스를 관리하는 서버가 존재하고
다수의 클라이언트가 리소스를 소비하기 위해 네트워크를 통해 서버에 접근하는 구조를 의미한다.
상태가 없는 Stateless
클라이언트가 서버에 요청을 보낼 때, 이전 요청의 영향을 받지 않았다는 것을 상태가 없다고 한다.
예를 들어,
1. /Login 으로 요청을 보내고 로그인이 되어 다음 페이지인 /page로 넘어감
2. /page로 리소스를 불러올 때 이전 요청에서 Login한 사실을 서버가 알고있는가?
이 때 서버가 Login 한 상태를 알고 있어야 한다면 이것은 상태가 있는 아키텍처이다.
반대로, 서버가 모르고 있다면 이것은 상태가 없는 아키텍처이다.
그럼 로그인은 어떻게 구현하고, 또 유지해야하는가?
클라이언트는 서버에 요청을 날릴 때 마다 요청에 리소스를 받기 위한 모든 정보를 포함해야한다.
리소스를 수정한 이유 수정한 상태를 유지해야하는 경우,
서버가 아닌 데이터베이스 같은 퍼시스턴스에 상태를 저장해야한다.
캐시 가능한 데이터
서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 한다.
캐시란 클라이언트가 다시 API를 호출하지 않고도 이전에 요청한 데이터를 가져오는 프로세스다.
캐시는 API의 성능을 향상시키고 네트워크 트래픽을 줄이는데 도움을 줄 수 있다.
캐시가 가능한 데이터의 예로는 다음과 같은 것들이 있다.
- 자주 변경되지 않는 데이터
- 자주 요청되는 데이터
- 크기가 큰 데이터
HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있다.
일관적인 인터페이스
시스템 또는 애플리케이션의 리소스에 접근하기 위한 인터페이스가 일관되어야 한다는 뜻이다.
일관적인 인터페이스는 API를 쉽게 이해하고 사용할 수 있게 도와준다.
일관적인 인터페이스를 달성하려면 다음과 같은 사항을 고려해야한다.
- 요청과 응답의 형식
- 리소스의 이름
- 리소스 간의 관계
- 오류 메시지
예를 들어,
어느 페이지를 로딩하기 위해 필요한 리소스를 요청하는 API가 "/project.com/update" 일 때,
이 페이지를 새로 업데이트하기 위해서 사용한 API가 "/project2.com/update" 라면,
이는 일관적인 인터페이스가 아니다.
또한,
똑같은 페이지의 어느 요청1에 대한 응답이 JSON이고
요청2에 대한 응답이 HTML이라면 일관적인 인터페이스가 아니다.
레이어 시스템
클라이언트가 서버에 요청을 날릴 때, 여러개의 레이어로 된 서버를 거칠 수 있다.
예를 들어 서버는 인증 서버, 캐싱 서버, 로드 밸런서를 거쳐서
최종적으로 애플리케이션에 도착한다고 했을 때,
이 사이의 레이어들은 요청과 응답에 어떤 영향을 미치지 않으며
클라이언트는 서버의 레이어 존재 유무를 알지 못한다.
레이어 시스템의 예는 다음과 같이 나눌 수 있다.
- 프레젠테이션 계층
- 사용자와 상호 작용하는 계층
- 비즈니스 계층
- API의 비즈니스 로직을 담당하는 계층
- 데이터 계층
- API의 데이터를 저장하는 계층
코드 온-디맨드
이 제약은 선택사항이다.
코드 온-디맨드는 API가 클라이언트에 코드를 전송할 수 있도록 하는 것을 말한다.
즉, 클라이언트는 서버에 코드를 요청할 수 있고, 서버가 리턴한 코드를 실행할 수 있게 되는 것.
