REST란 무엇이냐?

REST 란?

REpresentational State Transfer 의 약자로, 통신 규약이나 표준 또는 스펙이 아니라 분산 하이퍼미디어 시스템을 위한 www 같은 소프트웨어 아키텍처의 한 형식이며 네트워크 상에서 클라이언트와 서버 사이의 통신 방식이다. REST 라는 용어는 2000년 로이필딩(Roy Fielding) 박사의 논문에서 처음 소개되었다.

 

REST 구성요소

 

Resource

REST에서 가장 중요한 개념은 바로 유일한 ID를 가지는 Resource가 서버에 존재하고, 클라이언트는 각 Resource의 상태를 조작하기 위해 요청을 보낸다는 것이다. 일반적으로 Resource는 user, friends, group 등과 같은 명사형의 단어이고, HTTP에서 이러한 Resource 를 구별하기 위한 ID는 '/groups/{groupId}/member/101'와 같은 URI이다.

 

Method

GET, DELETE 등과 같이 Resource를 조작할 수 있는 동사형의 단어를 Method라고 한다. 클라이언트는 URI를 이용해서 Resource를 지정하고 해당 Resource를 조작하기 위해서 Method를 사용한다. HTTP에서는 GET, POST, PUT, DELETE 등의 Method를 제공한다. 

 

Representation of Resource

클라이언트가 서버로 요청을 보냈을 때, 서버가 응답으로 보내주는 Resource의 상태를 Representation이라고 한다. REST에서 하나의 Resource는 여러 형태의 Representation으로 나타내어 질 수 있다. 예를 들어 xml, json, text, rss 등으로 전달할 수 있다.

 

URI 구성

- URI는 ‘/groups’, ‘/users’ 등과 같이 직관적으로 어떤 정보를 제공하는지 알 수 있는 단어들로 구성

- URI는 ‘/groups/{groupId}/member/101’와 같이 URI path가 계층적인 구조를 가지도록 구성

- URI의 상위 path는 하위 path의 집합을 의미하는 단어로 구성. 예를 들어 ‘/groups/101/member/12532’의 경우 ‘groups’는 ‘101’ 등의 그룹의 집합이므로 ‘/groups’ 만으로도 그룹 목록이라는 정보를 제공할 수 있는 유효한 URI가 된다.

- CREATE / DESTORY/UPDATE/DELETE 등의 기본 CRUD 처리는 URI에 명시적으로 표현하도록 하여 URI를 보더라도 직관적으로 어떤 기능을 제공하는지 알 수 있도록 명명하도록 한다.

출처: http://naleejang.tistory.com/81 [Nalee의 IT이야기]

 

 

1. REST 정의

  - REST는 REpresentational State Transfer의 약자이다. 단순 정의는 그렇고, 실제적인 정의는 아마 ROA(Resource Oriented Architecture)를 따르는 웹 서비스 아키텍처 정도가 될 것이다. 하지만 이것만 봐서도 무엇인지 이해하기는 힘들다. 직관적으로 REST가 무엇이냐, 라고 한다면 "URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는것"이라고 하면 될 것 같다. 직관적인 URI를 이용해서 오브젝트의 멤버를 추적하는 것처럼 리소스에 접근하여 HTTP 메소드를 이용해 그것을 조작하는 것이다.


2. REST 특징

  사실 REST는 ROA를 위해 태어났다해도 과언이 아니기 떄문에, ROA의 4가지 속성(Addressability, Connectedness, Statelessness, Homogeneous Interface)과 깊은 연관이 있다.

  - Stateless : Statelessness
  REST의 가장 큰 강점 중 하나이다. 이전, 이후에 대한 직접적인 정보가 필요없이 직관적인 오브젝트에의 접근으로 서비스를 처리한다. 세션정보를 보관할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이라든지 기타 유연한 아키텍처의 적용이 가능하다. 쿠키/세션, 필요없다.

  - URI를 이용 : Addressability
  REST는 모든 유일한 오브젝트에 대해 유일하고 직관적인 URI을 통해 접근하도록 한다. 설명보다는 예를 하나 보는것이 간단한데, 서울대학교의 대학원생들 중 학번이 12345657인 사람의 정보를 얻어오고자 한다면 아래와 같이 표현 가능할것이다.

    www.univinfo.co.kr/seouluniv/undergraduate/1234567

  사실 단순히 저런식으로 표현하는것이 중요한게 아니라, 특정 오브젝트에 접근할때 특정 URI를 통한 접근이 가능한지가 중요하다. 인터넷 메일을 확인할때, 어떤 메일은 특정 주소에서 반드시 특정 링크를 클릭해야지만 메일을 확인할 수 있고, 어떤 메일은 특정 메일을 특정 주소로 접근 가능할 수 있다. 후자가 REST 서비스이다. (당장 지메일의 수신 메일 하나를 클릭한 후 브라우저 주소창에 뜬 주소를 살펴보면 알 수 있을 것이다)

  -  HTTP 메소드를 사용 : Homogeneous Interface
  Homogeneous의 해석에 따라 의미가 갈릴수도 있는데, 동종의 인터페이스만을 사용한다고 보면 된다. 즉, REST는 HTTP에서 제공하는 GET, PUT, POST, DELETE 4개의 메소드(여기에 HEAD나 OPTION을 추가하는 경우도 있다)를 이용해서 서비스를 제공한다. 한편으로는 이것이 REST의 단점이 되기도 하는데, 결국 HTTP 4개 메소드가 DB의 CRUD와 같은 기능을 하기 때문에(C:POST, R:GET, U:PUT, D:DELETE), 이러한 유형으로 분류할 수 없는 작업에 대해서는 어떻게 처리해야 할 지가 조금 모호해지기도 한다. (이메일을 보낸다든지...) 이런 경우 URI를 적절히 정의함으로써 가능하지만, 실제로 서비스별로 URI을 어떻게 정의할 것인가가 REST 설계에 있어 가장 어려운 부분이다.

  - Connectedness
  사실 이부분이 좀 애매하다... 연결성이란것이 서비스내 하나의 리소스가 다른 리소스들간의 관계에 의해 표현되어질 수 있다는 정도로 해석하면 될 것 같다.


3. 장단점

  - 가장 큰 장점은 쉽다는것이다. REST는 통용되는 표준 아닌 표준이 있기는 하지만, 사실 위의 특징들만 잘 지켜서 간결하게 서비스에 접근 가능하다면 그게 REST이다. REST를 지원하는 프레임워크라든지, 언어라든지 이런 도구들이 없어도 얼마든지 구현 가능하다. 이 얘기는 곧 기존의 자원들을 그대로 활용 가능하다는 뜻이 된다. REST 도입을 위해 무언가 굉장히 큰 노력을 기울일 필요가 없다는 것이다.
  반면 단점 역시 명확한데, 표준이 없다는게 단점이다. 각 서비스별로 아키텍처가 다르기 때문에, 이것에 따른 서비스 방안 역시 다를 수 밖에 없다. 그리고 설계나 구현 시에 머리를 써야한다. 단순 CRUD 만으로 표현 불가능한 서비스들이 많기 때문에 고민을 해보고 일을 해야 한다는 뜻이다. 생각없이 뚝딱뚝딱 만들다가는 위에서 얘기한 문제들에 봉착해서 이러지도 저러지도 못하는 수가 생긴다.