REST의 이해

 

 

1. REST (Representational Safe Transfer)

 

웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처.

HTTP와 JSON을 함께 사용하여 OPEN API를 구현하는 방법으로 주류를 이루고 있으며, 대부분의 OPEN API는 REST 아키텍처를 기반으로 설계 및 구현되고 있다.

 

2. REST의 기본

 

REST는 크게 리소스, 메서드, 메시지 3가지 요소로 구성된다. 예를 들어서 'ID가 3인 사용자를 삭제한다'라는 호출이 있을 때 '사용자'는 생성되는 리소스, '삭제한다'라는 행위는 메서드, 'ID가 3인 사용자'는 메시지가 된다.

 

A. HTTP 메서드

 

 HTTP에는 여러가지 메서드가 있지만, REST에서는 CRUD(Create Read Update Delete)에 해당하는 4가지의 메서드만 사용한다.

 

메서드	의미	Idempotent
POST	Create	No
GET	Select	Yes
PUT	Update	Yes
DELETE	Delete	Yes

 

Idempotent는 여러 번 수행해도 결과가 같은 경우를 의미한다. 예를 들어 a++은 Idempotent 하지 않다고 하지만, a = 4와 같은 명령은 반복적으로 수행해도 Idempotent하다.

 

B. REST의 리소스

 

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

 

- 사용자 생성

 

 다음은 http://myweb/users라는 리소스를 이름은 john, 주소는 seoul이라는 메시지로 HTTP POST를 이용해서 생성하는 정의이다.

 

 HTTP POST, http://myweb/users/

{

"name" : "john",

"address" : "seoul"

}

 

- 조회

 

 다음은 생성된 리소스 중에서 http://myweb/users라는 사용자 리소스 중에 ID가 john인 사용자 정보를 조회해오는 방식이다.

 

HTTP GET, http://myweb/users/john

 

- 업데이트

 

 다음은 http://myweb/users라는 사용자 리소스 중에 ID가 john인 사용자 정보에 대해 주소를 suwon으로 수정하는 방식이다.

 

HTTP PUT, http://myweb/users/john

{

"name" : "john",

"address" : "suwon"

}

 

- 삭제

 

 마지막으로 http://myweb/users라는 사용자 리소스 중에 ID가 john 사용자 정보를 삭제하는 방법이다.

 

HTTP DELETE, http://myweb/users/john

 

3. REST의 특성

 

- 유니폼 인터페이스 

 

 REST는 HTTP 표준에만 따른다면 어떠한 기술이든지 특정 언어나 기술에 종속 받지 않고 사용할 수 있는 인터페이스 스타일이다.

 

- 무상태성 (Stateless)

 

 사용자나 클라이언트의 컨텍스트를 서버쪽에 유지하지 않는다라는 의미로, HTTP 세션과 같은 컨텍스트 저장소에 상태 정보를 저장하지 않는 형태를 의미한다. 각 API 서버는 들어오는 요청만을 들어오는 메시지로 처리하면 되며, 세션과 같은 컨텍스트 정보를 신경 쓸 필요가 없다.

 

- 캐시 가능

 

 HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.

 

- 자체 표현 구조

 

 REST의 가장 큰 특징 중 하나는 API 메시지만 보고도 이를 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다. 리소스와 메서드를 이용해서 어떤 메서드에 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해할 수 있는 구조이다.

 

- 클라이언트 서버 구조

- 계층형 구조

 

 

4. REST 안티 패턴

 

      - GET/POST를 이용한 터널링

 

 http://myweb/users?method=update&id=john 경우가 전형적인 GET을 이용한 터널링이다. 메소드의 실제 동작은 리소스를 업데이트 하는 내용인데 PUT을 사용하지 않고 GET에 쿼리 파라미터로 수정 메서드임을 명시하였다. 굉장히 안 좋은 디자인이며, HTTP 메서드 사상을 따르지 않았기 때문에 REST라고 부를 수 없다.

 

 또 다른 한 가지의 예로는 Create 오퍼레이션이 아닌데도 불구하고, 아래와 같이 JSON body에 오퍼레이션 명을 넘기는 형태이다.

 

HTTP POST, http://myweb/users/

{

"getuser" : {

"id" : "john"

}

}

 

- 자체 표현 구조를 사용하지 않는 경우

- HTTP 응답 코드를 사용하지 않는 경우

 

 성공은 200, 에러는 500과 같이 1~2개의 HTTP 응답 코드만을 사용하는 경우.

심한 경우 예를 들어, HTTP 응답 코드 200으로 정의하고 별도의 에러 메시지를 200 응답 코드와 함께 보내는 경우도 있다.

 

 

5. REST API 디자인

 

REST URI는 단순하고 직관적으로 만들어야 한다.

 

/posts

/posts/1234

 

URI에 리소스 명은 동사보다는 명사를 사용한다.

예를 들어서 다음은 /posts라는 리소스를 생성하라는 의미가 된다.

 

POST /posts

 

아래는 잘못된 예이다.

 

HTTP POST : /getPosts

HTTP POST : /setPosts

 

get/set 등의 행위를 URL에 붙인 경우는 좋지 않은 예이다. 또한 될 수 있으면 단수형 명사 보다는 복수형 명사를 사용하는 것이 의미상 표현하기가 더 좋다.

 

 

6. REST의 문제점

 

- 표준 규약이 없다. 그래서 관리가 어렵다.

- 전통적인 RDBMS에 적용하기가 쉽지 않다.

 

 

 

 

 

 

참조 저서 : 조병욱(조대협), 대용량 아키텍처와 성능 튜닝, 프리렉 출판, 137쪽