[Network] REST란 무엇인가?

1. REST 정의

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

 -  DB의 내용 등을 전부 하나의 자원으로 파악하여 각 자원의 고유한 URI(Uniform Resource Identifier)를 부여하고, 해당 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 HTTP의 기본 명령어인 POST, GET, PUT, DELETE를 통해서 처리한다.

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 설계에 있어 가장 어려운 부분이다.

 

Method	CRUD	SQL
POST	Create	INSERT
GET	Read	SELECT
PUT	Update	UPDATE
DELETE	Delete	DELETE

 

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

3. 장단점

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