Rest API

이번 포스팅에서는 REST API 에 대해 쓰려한다.

사실 Google drive API 를 연동하는 블로그를 쓰다가 곁다리로 추가하는 거라 상세히 다루지는 않겠다.

Rest API?

Representational State Transfer API 의 약자.

HTTP URI 를 통해 자원을 명시하고, HTTP method(post, get, put, delete) 를 통해 CRUD(create, read, update, delete) 를 처리하는 방식이다.

POST	자원 생성(Create)
GET	자원 조회(Read)
PUT	자원 수정(Update)
DELETE	자원 삭제(Delete)

Rest API 구성요소

◼ Resource

- 모든 자원은 서버에 존재하고 각 자원은 고유 ID 가 존재한다.

- 자원을 구별하는 ID 는 HTTP URI 다.

- 클라이언트는 URI 를 이용하여 서버에 요청할 수 있다.

 

◼ Method

- HTTP method (post, get, put, delete) 를 이용한다.

- HTTP method 로 CRUD (create, read, update, delete) 를 처리한다.

 

◼ Representation of resource

- 클라이언트 & 서버가 데이터를 주고 받는 형태로 JSON, XML, TEXT, RSS 등이 있다.

- 최근에는 JSON 을 주로 사용한다.

Rest API 특징

◼ Uniform Interface (유니폼 인터페이스)

- URI 로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.

- HTTP 를 따르는 모든 플랫폼에서 사용 가능한다.

 

◼ Stateless (무상태성)

- REST 는 무상태성을 갖는다.

- 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.

- API 서버는 들어오는 요청만을 단순히 처리하여 부담을 줄이고, 서비스의 자유도가 높아진다.

 

◼ Cacheable (캐시 가능)

- HTTP 가 가진 캐싱 기능이 적용 가능하다.

- 캐시 사용으로 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킨다.

 

◼ Self-descriptiveness (자체 표현 구조)

- REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다.

 

◼ Client - Server 구조

- REST 서버는 API 를 제공하고 로직 처리 및 저장을 책임진다. 

- 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리한다.

- 각각의 역할이 확실히 구분되어 서로간의 의존성이 줄어든다.

 

◼ Layered System (계층형 구조)

- 클라이언트는 REST API server 만 호출한다.

- REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조를 변경할 수 있다.

- PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.