REST 살펴보기

단순히 하나의 브라우저만 지원하던 예전과 달리, 멀티 플랫폼, 멀티 디바이스 사용이 당연시되는 지금의 서버 프로그램은 여러 웹브라우저뿐만 아니라 아이폰, 안드로이드 등의 어플리케이션과의 통신에도 대응해야 한다. 특정 플랫폼이나 디바이스에 의존적인 서버를 만들지 않기 위해서는 범용적인 사용성을 보장하는 서버 디자인이 필요하다.

 

이를 위해 고안된 것이 REST 이다. REST의 기본 원칙을 성실히 지킨 서비스 디자인을 “RESTful 하다.” 라고 표현하며, 이러한 원칙을 지켜서 설계된 API를 “Rest API”라고 한다.

 

REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 스타일이다. 이는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장해 준다.

 

REST 구성요소

1. 자원(Resource) – URI

Unique한 ID를 가진 Server의 Resource에 대해 Client가 요청을 보낸다.

2. 행위(Verb) - Method

Client가 Server에 요청을 보내는 방식으로 POST, GET, PUT, DELETE 등이 있다.

3. 표현(Representations)

Server와 Client간의 데이터 전달 형태로 json, xml, text 등이 있다. 주로 Key-Value를 활용하는 Json이 사용된다.

REST를 구성하는 스타일 (제약조건)

1. client - server(서버-클라이언트 구조)

RestAPI에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할을 확실히 구분시킴으로써 서로간의 의존성이 줄어들게 된다.

2. stateless(무상태성)

각각의 요청을 별개의 것으로 인식하고 처리해야 하며,이전 요청이 다음 요청에 연관되어서는 안 된다.그래서 RestAPI는 세션정보나 쿠키 정보를 활용하여 작업을 위한 상태 정보를 저장 및 관리하지 않는다. 이러한 무상태성때문에 RestAPI는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 이러한 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함입니다.

3. cacheable(캐싱가능)

RestAPI는 HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 활용할 수 있다. 그러므로 RestAPI에서도 캐싱 기능을 적용할 수 있는데, HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효율적으로 처리할 수 있게 도와준다.

4. layered system(계층형 구조)

RestAPI의 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해준다.

5. code-on-demand(optional)

서버에서 코드를 client로 보내서 실행할 수 있어야 한다.(ex>javascript)

6. uniform interface(일관된 인터페이스)

Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다. 이것은 요청을 하는 Client가 플랫폼(Android, IOS, JSP 등) 에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 의미하고, 이러한 특징 덕분에 RestAPI는 HTTP를 사용하는 모든 플랫폼에서 요청 가능하며,느슨한 결합) 형태를 갖게 되었다.

현재(현실)의 REST API 한계점

HTTP만 잘 따라도 대체로 REST 제약조건(아키텍쳐 스타일)을 다 만족할 수 있지만, uniform interface 제약조건의 일부를 만족시키지는 못한다.

① identification of resources : 
    uri가 리소스로 식별되면 된다.

② manipulation of resources through representations : 
    리소스에 대한 조작 시 http 메세지에 표현을 담아서 전송해서 달성하면 된다.

③ self-descriptive messages : 
    메시지는 스스로를 설명해야 한다.

④ hypermedia as the engine of application state(HATEOAS) : 
    애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다..

위처럼 uniform interface는 4가지 제약조건으로 이루어져 있는데, 오늘날 사용되는 대부분의 RestAPI는 아래 두 가지 ③, ④는 지키지 못하고 있다.

 

REST의 기본 원칙을 성실히 지키지 않은, ‘RESTful 하지 않은’ 오늘날 대부분의 REST API를 어떻게 해야 할지에 대해 고민해볼 필요가 있다.

  - REST API가 아니지만 REST API라고라고 부른다. (현재 상태)

  - REST API 구현을 포기하고 HTTP API라고라고 부른다.

  - REST API를 구현하고 REST API라고라고 부른다.

사실 어떻게 부르든 큰 차이는 없을 수 있지만, REST의 지향점에 대한 이해는 가져야 하지 않을까 생각해본다.

 

<Reference>

• 위키 피디아(REST) https://ko.wikipedia.org/wiki/REST
• 토스트 밋업(REST API 제대로 알고 사용하기) https://meetup.toast.com/posts/92
• 망나니 개발자([Server] Restful API란?) https://mangkyu.tistory.com/46?category=761303

글. 기술지원 2팀 | 권선보 차장

기획/편집. 프리세일즈·마케팅팀 | 박병민 대리