반응형
안녕하세요. 남산돈가스입니다.
오늘은 REST 란 무엇인가에 대해서 알아보려고 합니다.
REST란 Represendtational State Transfer의 약자로 소프트웨어 아키텍처의 한 형식으로 정의되어있습니다. 이 용어는 2000년 로이 필딩(Roy Fielding)의 박사학위 논문에서 처음으로 소개되었습니다.
당시 로이 필딩은 웹(HTTP)이 설계의 우수성에 비해 제대로 사용 되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표 하였습니다.
그렇다면, REST 하다는 것은 어떤 것을 의미할까요?
제가 이해하기 쉽게 정의한 "REST하다" 는 것은 웹에서 제공하는 모든 자원들에 각자 고유한 URI를 정의해 그 URI만 보더라도 해당 자원들의 명세를 표현하고 이해할 수 있게하는 디자인 방식(?) 방법론(?) 이라고 생각합니다. 따라서 RESTful API는 REST의 설계방식을 반영한 API를 제공한다는 것을 의미할 수 있습니다.
여기서 말한 REST의 구성은 어떤 것이 있는지 알아보겠습니다.
REST의 구성
REST 특징
오늘은 REST 란 무엇인가에 대해서 알아보려고 합니다.
REST란 Represendtational State Transfer의 약자로 소프트웨어 아키텍처의 한 형식으로 정의되어있습니다. 이 용어는 2000년 로이 필딩(Roy Fielding)의 박사학위 논문에서 처음으로 소개되었습니다.
당시 로이 필딩은 웹(HTTP)이 설계의 우수성에 비해 제대로 사용 되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표 하였습니다.
그렇다면, REST 하다는 것은 어떤 것을 의미할까요?
제가 이해하기 쉽게 정의한 "REST하다" 는 것은 웹에서 제공하는 모든 자원들에 각자 고유한 URI를 정의해 그 URI만 보더라도 해당 자원들의 명세를 표현하고 이해할 수 있게하는 디자인 방식(?) 방법론(?) 이라고 생각합니다. 따라서 RESTful API는 REST의 설계방식을 반영한 API를 제공한다는 것을 의미할 수 있습니다.
여기서 말한 REST의 구성은 어떤 것이 있는지 알아보겠습니다.
REST의 구성
자원의 식별 (Resource)
요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.
메시지를 통한 리소스의 조작 (Verb)
클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
자기서술적 메시지 (Representations)
각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.
애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어 (HATEOAS)
만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.
1) Client - Server
클라이언트는 온전히 사용자와 관련 된 처리를 담당하며, 서버는 해당 요청을 처리하여 클라이언트로 요청에 대한 응답을 전달하는 역할만 담당한다. REST 서버라고 한다면, 서버는 API를 제공하고, 제공 된 API로 비즈니스 로직 및 데이터 처리를 책임진다. 클라이언트는 사용자 인증 및 Context 등을 직접 관리하고 책임진다.
이렇게 역할이 각각 확실히 구분되어 있어, 클라이언트와 서버에서 개발해야하는 내용들이 명확하게 구분되고 의존성이 줄어들게 된다.
2) Stateless
Stateless 하다는 것은 클라이언트의 Context를 서버 쪽에 유지 하지 않는다는 의미로, Session이나 Context 저장소에 클라이언트의 상태 정보를 저장하지 않는 다는 것을 의미한다. 이런 경우, 서버는 요청에 대한 처리만 담당하면 되며, Session 등 Context 정보를 관여할 필요가 없어지기 때문에 구현이 단순해집니다.
3) Cacheable
REST의 가장 큰 특징 중 하나인 HTTP 기존의 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다는 점입니다. 그렇기 때문에 HTTP에서 강력하게 제공하는 캐싱기능을 사용할 수 있습니다.
4) Self-descriptiveness
JSON, XML 등 다양한 포맷을 사용하여 직관적으로 이해할 수 있으며, REST API 메시지만으로도 그 요청이 어떤 행위를 하는 지 알 수 있습니다.
5) Layered System
위에서 말했듯이 클라이언트와 서버가 분리되어 있기 때문에 중간에 사용자 인증, 게이트웨이, 암호화 처리, 프록시 등 중간매체를 사용할 수 있어 자유도가 높습니다.
6) Uniform Interface
Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍처 스타일을 말한다.
여기까지 이번 포스팅에선 REST의 정의, 구성, 특징에 대해서 알아보았습니다. 이제 다음 포스팅에선 이렇게 설명한 REST를 기반으로 RESTful한 API를 설계하는 법에 대해서 알아보겠습니다.