REST의 기본

REST의 기본

구체적인 뜻은 검색하면 무수히 나오기 때문에 기본적인 핵심만 설명하려 합니다.

리소스, 메서드, 메시지 3가지로 이루어져 있다.

예를 들어 "이름이 노엘인 사람을 찾아간다" 라는 호출을 하면

"사람"은 생성되는 리소스, "찾아간다" 라는 행위는 메서드, 그리고 "이름이 노엘인 사람"은 메시지가 된다.

HTTP 메서드

REST에서는 행위에 대한 메서드를 HTTP 메서드를 그대로 사용한다.

ex) HTTP POST, http://web/person/
{
    "person":{
        "name":"noel"
 
    }
}
 

HTTP에서는 여러가지 메서드가 있다.

하지만, REST에서는 CRUD에 해당하는 4가지 메서드만 사용한다.

여기서 중요한 개념이 Idemopotence(멱등성) 라는 것이 있다.

멱등성이란?

연산을 여러번 적용하더라도 결과가 달라지지 않는 즉, 항상 같은 결과를 말한다.

POST의 연산의 경우에는 리소스를 새로 추가하는 CREATE에 해당하는 연산이기 때문에 Idemopotence(멱등성 이하 멱등성) 가지지 않습니다. 하지만, GET, PUT, DELETE에 해당하는 SELECT, UPDATE, DELETE에 해당하는 게시물의 카운트를 늘려준다는 등의 기능을 가지고 있는 메서드는 항상 멱등성을 가지고 있어야 합니다.

REST는 API를 상태 없이 수행하기 때문에 해당 REST API를 다른 API와 함께 호출했는데 실패할 경우, 트랜잭션을 복구하기 위해서 다시 실행해야하는 경우에 멱등성이 없는 메서드들은 기존 상태를 저장했다가 다시 원복해줘야하지만

멱등성이 있는 메서드는 반복적으로 다시 메서드를 수행해주면 됩니다.

CREATE의 경우에는 반복적으로 메서드를 수행한다고 해서 기존에 있던 상태를 재정의 할 수 없기 때문입니다.

REST의 리소스

REST는 리소스 지향 아키텍쳐 스타일이다.

모든 것을 명사로 표현하는 URI 특성을 가지고 있다.

그리고 각 세부 리소스에는 id를 부여하여 위의 http 예시로 볼 때 http://web//person//noel 라는 형태로 사람이라는 리소스 타입의 id가 noel인 리소스를 정의할 수 있다.

REST의 특성

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

REST는 HTTP 표준에만 따른 다면, 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일이다.

HTTP + JSON으로 REST API를 정의했다면 어떤 언어나 기술에 종속 받지 않고 모든 플랫폼에 사용이 가능하다. 

하지만, JSON은 하나의 선택일뿐, 꼭 JSON일 필요는 없다. XML의 경우 프레임웍과 결합하여 메시지 구조를 더 명시적으로 정의할 수도 있다.

2. 무상태성(Stateless)

REST는 REpresentional State Transfer의 약자로써 Stateless(무상태성)가 또 하나의 특징이다.

보여주는 쪽에 더 힘을 실어 클라이언트 단의 컨택스트를 서버쪽에 부담하지 않는다는 의미로, 쉽게 표현하면 Session과 같은 컨택스트 저장소에 상태 정보를 저장하지 않는 형태를 의미한다.

필요한 정보만을 Game API를 통해서 받아오는 등의 형태가 무상태성(Stateless)라고 봐도 될 것 같다.

이러한 구조는 곧 각 API 서버는 들어오는 요청만을 메시지로 처리하고 세션과 같은 컨텍스트 정보는 신경쓸 필요가 없어 구현이 매우 단순해진다.

3. 캐쉬가능(Cacheable)

REST의 큰 특징 중 하나는 HTTP라는 기존의 웹 표준을 그대로 사용한다는 것이다.

때문에 웹에서 사용하는 기존의 인프라를 그대로 활용하는 것이 가능하다.

로드밸런서나 SSL, Caching 기능을 적용할 수 있다.

쉽게 E-TAG나 "Last-Modified"태그를 사용하면 Caching을 구현 할 수 있다고 한다.

만약에 클라이언트 측에서 HTTP GET을 "Last-Modified" 값과 함께 sending 하면 컨텐츠 변화가 없을 경우에 REST 컴포넌트는 "304 Not Modified"를 리턴하면서 클라이언트 측에서 Caching 된 데이터를 사용할 수 있게 만들어준다.

이런식으로 Caching 기능을 사용함으로 서버의 자원의 활용률을 매우 향상시킬 수 있다.

4. 자체표현구조(Self-descriptiveness)

REST의 경우에는 REST API 자체가 매우 쉬워 API 메시지만 보고도 API를 이해할 수 있다.

또한, 리소스와 메서드로 어떤 행위를 하는지 알 수 있으며 메시지 포맷도 JSON이므로 아주 직관적이라고 할 수 있다.

5. 클라이언트 서버 구조

REST 서버는 API를 제공하고, 제공된 API를 통해서 비즈니스 로직 처리 및 저장을 담당한다.

클라이언트 측에서 인증, 컨택스트 등을 직접 관리하고 책임지는 역할로 나아가고 있다.

따라서 이러한 구조로 인해서 서버측과 클라이언트 측 간의 의존성이 줄어들고 Role 구분을 명확하게 할 수 있다.

REST 사용시 하지말아야 할 패턴

1. GET/POST를 이용한 터널링

http://web/person?method=update&id=noel 

위의 경우가 전형적인 GET 방식을 통한 터널링이다.

HTTP의 PUT을 사용하지 않고 GET에 쿼리로 method=update라고 표현하면서 수정 메서드임을 명시했다.

굉장히 안좋은 디자인이고, REST라고 볼 수 없다.

HTTP POST, http://web/person/
{
    "getperson" : {
        "id" : "noel",
    }
}
 

위의 경우에도 CREATE가 아닌데도 불구하고 JSON 바디에 오퍼레이션 명을 남기는 것으로 매우 좋지않은 POST를 이용한 터널링이라고 볼 수 있다.

2. Self-descriptiveness를 사용하지 않음

자체표현구조를 사용하지 않는 것은 위에서 서술한 GET이나 POST를 이용한 터널링이 대표적으로

이해할 수 없는 구조를 사용하는 것이다.

3. HTTP Response code를 사용하지 않음

Http Response code인 <성공 200, 실패 500>과 같이 몇가지 코드만을 사용하는 경우다. 이는 REST 디자인에도 맞지않고Self-descriptiveness에도 어긋난다.

위와 같이 REST API 에 대해서 이해하기 쉬운 글을 만나 쉽게 작성할 수 있었다.

이 글을 포스팅해주신 조대협님에게 감사의 인사를 전한다.

출처 : 

http://bcho.tistory.com/953?category=252770

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/ETag

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Last-Modified