Skip to content

Latest commit

 

History

History
61 lines (54 loc) · 3.65 KB

REST_API.md

File metadata and controls

61 lines (54 loc) · 3.65 KB

REST API

  • REST(Representational safe transfer): 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐

REST 의 기본

REST 는 크게 리소스, 메소드, 메시지 3가지 요소로 구성된다.
"이름이 haeun 인 사용자를 생성한다" 라는 호출이 있을 때, "사용자" 는 생성되는 리소스, "생성한다" 라는 행위는 메소드, "이름이 haeun" 은 메시지가 된다.

HTTP 메소드

REST 는 행위에 대한 메소드를 HTTP 메소드 그대로 사용한다. HTTP 에는 여러 메소드가 있지만 그 중에서도 CRUD 에 해당하는 4가지의 메소드만 사용한다.

CRUD (Create Read Update Delete)

메소드 의미
POST Create
GET Select
PUT Update
DELETE Delete

REST 의 리소스

REST 는 리소스 지향 아키텍처 스타일 이라는 정의 답게 모든 것을 리소스, 즉 명사로 표현을 하며 각 세부 리소스에는 id 를 붙인다.

REST 의 특성

  • 유니폼 인터페이스(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 컴포넌트가 위치한 서버에 트랜잭션을 발생시키지 않기 때문에 
전체 응답시간과 성능 그리고 서버의 자원 사용률을 굉장히 향상시킬 수 있다. 
  • 자체 표현 구조