RESTful API

개발을 하다보면 REST와 REST API라는 표현을 자연스럽게 접하게됩니다.

 

또한 다음과 같은 설명으로 많이 접했을 것입니다.

REST API
1. URI를 통해 자원을 지정
2. HTTP 메서드 : 자원에 대한 행위 표현

HTTP 메서드를 통해 해당 자원에 대해 어떠한 행동을 할 것인지를 명시하는 API인데, 예를 들어 사용자라는 자원에 대해 CRUD 작업을 하고 싶다면, /user와 같은 URI로 사용자라는 자원을 지정하고 POST,GET,PUT,DELETE를 통해 사용자에 대한 생성, 조회, 수정, 삭제 작업을 처리하는 것을 말합니다. 

 

CREATE    POST        /user
READ        GET           /user/1
UPDATE    PUT          /user/1
DELETE    DELETE    /user/1

그러나 REST라는 개념을 만든 Roy T. Fielding은 자신의 블로그에서 다음과 같은 말을 남겼다고 합니다.

내 논문 어디에도 CRUD에 대한 내용은 없다.
HTTP 메서드는 REST가 아니라 웹의 아키텍쳐 스탕일의 일부다.
HTTP에서 정의한 방식대로만 잘 쓴다면 REST는 딱히 할 말이 없다.

즉 앞서 이야기한 REST API에 대한 정의는 REST의 본질과는 조금 차이가 있다는 것이죠.

그렇다면 Roy T. Fielding이 생각하는 REST API란 대체 무엇일까요?

* REST API
REST 아키텍쳐 스카일에 부합하는 API

그의 박사학위에 REST에 대해 다루는 챕터를 찾아서 읽어보면 REST와 관련된 제약 조건들을 볼 수가 있는데요, 그 중 Uniform Interface에만 초점을 맞춰보겠습니다. 

 

Uniform Interface는 4가지 제약 조건들로 구성됩니다.

 

1. identification of resources // 자원의 식별

2. manipulation of resources through representations // 표현을 통한 자원의 조작

3. self-descriptive messages // 자기 서술적 메세지

4.HATEOAS(hypermedia as the engine of application state)

 

이 4가지를 충적해야 rest API라고 부를 수 있다라는 것이 Roy T. Fielding의 주장입니다. 

그렇다면 하나씩 알아봅시다

 

1. identification of resources - 자원에 대한 식별

 

이 때 말하는 자원이란 기본적으로 이름을 지닐 수 있는 정보 및 개념적인 대상을 의미합니다. 이는 컴퓨터에 존재하는 문서나 이미지 외에도 사람과 같이 현실에 실존하는 대상도 이에 포함 될 수 있습니다. 이 때 중요한 점은 Roy T. Fielding은 이런 자원을 일종의 객체로 인식했다는 점입니다. 기본적으로 객체는 없었다가 생성되고 상태가 변화하고 파괴되어 없어진다는 특성을 지니고 있습니다. 그렇기 때문에 이러한 객체를 식별하기 위해서는 해당 객체의 현재상태를 보는 것만으로 부족하고 객체에 대해 언제나 변하지 않는 불변 값, 즉 고유한 식별자를 부여해주어야합니다. 그러므로 서버의 개별 자원에 대한 고유한 식별자로 URI를 사용해야한다는 것이 첫 번째 제약 조건의 의미입니다.

 

2. manipulation of resources through representations - 표현을 통한 자원의 조작

표현을 통해 자원에 대해 조작해야한다라는 제약 조건이 있습니다. 표현이란 기본적으로 특정한 상태에 있는 자원에 대한 표현을 의미하는데요, 자원은 다양한 방식으로 표현될 수 있습니다. 그러므로 클라이언트에서는 user/1 에 대해 GET 요청을 서버로 날리면 서버는 사용자 1이라는 자원의 현재 상태를 HTTP entity로 표현하여 응답할 수 있습니다. 한편 이미지라는 자원의 기대되는 초기 상태를 이미지 파일이라는 형식으로 표현하고 이 표현을 담은 POST 요청을 보내고 이를 바탕으로 새로운 이미지 자원을 생성하고 image/1 이라는 URI로, 식별자를 할당할 것입니다.

3. self-descriptive messages - 자기 서술적 메세지 

클라이언트와 서버를 오가는 메세지는 그 자체로 스스로에 대해 충분히 설명할 수 있어야한다는 것입니다.

클라이언트와 서버 사이의 컴포넌트들은 메세지의 내용을 참고하여 적절한 작업을 수행하게 됩니다. 따라서 클라이언트와 서버에서 보내는 요청 및 응답 메세지들은 이 컴포넌트들에게 자신을 어떻게 처리해야하는지에 대해 정확히 설명할 수 있어야한다는 것입니다.

설명 방법은 다음과 같습니다.

1. HOST 헤더에 도메인명 기재 필요// 나는 어디로 보낸 요청이다에 대한 정보를 포함해야만 자기 서술적입니다.

2. 캐쉬 관련 헤더를 토안 캐쉬 전략 지정 

4. HATEOAS(hypermedia as the engine of application state)

홈 이메일 이미지로 이루어진 사이트가 있다고 한다면 개별 URI 를 입력하지 않아도 렌더링된 HTML의 앵커 태그 등을 활용하여 해당 페이지로 이동하는 방법도 가능할 것입니다. 기본적으로 이 처럼 홈페이지에서 /email 페이지로 이동하는 것을 application의 상태를 변경하는 것을 의미하는데, HATEOAS란 HTML과 같은 하이퍼미디어를 통해 클라이언트가 어플리케이션의 상태를 변경할 수 있는 인터페이스를 제공해야한다는 것입니다. 만약 숨겨진 경로가 존재한다면 HATEOAS에 위반되는 것이라고 할 수 있습니다

 

웃프게도 Roy T. Fielding는 REST API는 기본적으로 비효율적이라고 말하며 상황에 따라 최적이 아닐 수 있다라고 말했습니다...