- REST(Representational safe transfer): 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐
REST 는 크게 리소스
, 메소드
, 메시지
3가지 요소로 구성된다.
"이름이 haeun 인 사용자를 생성한다" 라는 호출이 있을 때, "사용자" 는 생성되는 리소스, "생성한다" 라는 행위는 메소드, "이름이 haeun" 은
메시지가 된다.
REST 는 행위에 대한 메소드를 HTTP 메소드 그대로 사용한다. HTTP 에는 여러 메소드가 있지만 그 중에서도 CRUD 에 해당하는 4가지의 메소드만 사용한다.
CRUD (Create Read Update Delete)
메소드 | 의미 |
---|---|
POST | Create |
GET | Select |
PUT | Update |
DELETE | Delete |
REST 는 리소스 지향 아키텍처 스타일 이라는 정의 답게 모든 것을 리소스, 즉 명사로 표현을 하며 각 세부 리소스에는 id 를 붙인다.
- 유니폼 인터페이스(Uniform Interface)
REST 는 HTTP 표준에만 따른다면 어떠한 기술이든 사용 가능한 인터페이스 스타일이다.
예를 HTTP + JSON 으로 REST API 를 정의했다면, 특정 언어나 기술, 플랫폼(ex. 안드로이드, ios 등)에 종속받지 않고
HTTP 와 JSON 을 사용할 수 있는 모든 플랫폼에 사용이 가능하다.
> JSON 은 하나의 옵션일 뿐, 메시지 포맷이 꼭 JSON 이어야할 필요는 없다.
- 무상태성 (Stateless)
REST 는 상태를 유지하지 않는 것이 특징이다.
상태가 있다 없다의 의미는 사용자나 클라이언트의 컨택스트를 서버 쪽에 유지하지 않는다는 의미로,
쉽게 표현하면 HTTP Session 과 같은 컨택스트 저장소에 상태 정보를 저장하지 않는 형태를 의미한다.
상태 정보를 저장하지 않으면 각 API 서버는 들어오는 메시지로 들어오는 요청만 처리하게 되며,
세션과 같은 컨택스트 정보를 신경쓸 필요가 없기 때문에 구현이 단순해진다.
- 클라이언트 서버 구조
REST 서버는 API 를 제공하고, 제공된 API 를 이용해서 비즈니스 로직 처리 및 저장을 책임진다.
클라이언트의 경우 사용자 인증이나 컨택스트 등을 직접 관리하고 책임지는 구조로 역할이 나뉘어 지고 있다.
이렇게 역할이 확실하게 구분되면서 개발관점에서 클라이언트와 서버에서 개발해야 할 내용들이 명확하게 되고
서로의 개발에 있어서 의존성이 줄어들게 된다.
- 캐싱 가능(Cacheable)
REST 의 큰 특징 중 하나는 HTTP 라는 기존의 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다.
HTTP 프로토콜 기반의 로드 밸런서나 SSL 은 물론이고, HTTP 가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할 수 있다.
일반적인 서비스 시스템에서 60% 많게는 80% 가량의 트랜잭션이 Select 와 같은 조회성 트랜잭션인 것을
HTTP 의 리소스들을 웹캐시 서버 들레 캐싱하는 것은 용량이나 성능 면에서 많은 장점을 가지고 올 수 있다.
구현은 HTTP 프로토콜 표준에서 사용하는 "Last-Modified" 태크나 E-Tag 를 이용하면 캐싱을 구현할 수 있다.
캐시를 사용하게 되면 네트워크 응답시간 뿐 아니라 REST 컴포넌트가 위치한 서버에 트랜잭션을 발생시키지 않기 때문에
전체 응답시간과 성능 그리고 서버의 자원 사용률을 굉장히 향상시킬 수 있다.
- 자체 표현 구조