REST에 대하여

REST 

Rest(Representational State Transfer)은 WWW(World Wide Web)과 같은 분산 시스템을 위한 소프트웨어

아키텍쳐로 특히, 웹 API 디자인을 위한 지배적인 모델로 각광받고 있다. 아키텍처의 특징은 다음과 같다.

• Performance
• 확장성(Scalability): 많은 수의 컴포넌트로 이루어진 시스템에서 HTTP를 기반으로 하는 REST는 특히 확장성 측면에서 뚜렷한 강점을 보인다.
• 인터페이스의 단순화
• 필요한 컴포넌트만 수정할 수 있다. (애플리케이션 실행 중에도 가능하다.)
• 프로그램 코드와 데이터의 컴포넌트화로 높은 이식성
• 시스템 실패에 대한 강력한 저항성

REST 이전에

REST 도 결국은 네트워크 상에서 HTTP를 기반으로 정보를 제어하기 위한 방법론 중 하나다.

비교적 최근에 등장한 방법론인데, 이전에는 어떤 방법들이 있었는지 살펴보자

• RMI
• SOAP
• Corba
• DEC
• DCOM

다양한 방법들이 있다. 이들을 만든 벤더들의 목록은 다음과 같다.

• Sun
• Microsoft
• IBM
• OASIS,
• OMG

이렇게 다양한 방법들이 있는데, 거대 벤더들의 지원까지 받을 수 있는데 왜 REST라는 방법이 개발됐고, 게다가 이렇게 까지 관심을 받게 됐을까.? 기존방식들에 어떤 문제가 있는건가 살펴보니

• 상호운용성이 나쁘다. 거대 벤더들이 만든 방법들의 대부분이 그렇듯이, "강력하지만 복잡한 경우"가 많다. 복잡하면 상호운용성이 떨어지기 마련이다.
• 벤더에 종속적이다. 물론 툴을 개발한 벤더는 누구나 사용할 수 있는 방법이라고 설명을 하긴한다. 하지만 대게는 "운영체제에 종속적이거나", "복잡해서 벤더의 지원이 없으면 제대로된 애플리케이션 개발이 힘들다거나" 등등의 이유로 사실상 벤더에 종속되는 경우가 많다.
• 바퀴를 만들기 위해서 바퀴를 만들어야 한다. 복잡하다는 이야기다.

등의 문제가 발견됐다. 이러한 문제들을 해결하기 위해서 REST를 만들었다.

 

HTTP와 REST

REST에 대한 복잡한 설명이 많은데, 다음과 같이 요약할 수 있다.

• URI를 이용해서 제어할 자원을 명시하고
• HTTP를 이용해서 제어명령을 내린다.

원격에 명령을 내리는 것은 결국 원격에 있는 자원을 제어하겠다라는 의미다. REST는 원격에 있는 자원을 찾기 위해서 URI를 사용한다. 자원을 찾았다면, 이제 자원에 대한 명령을 내려야 하는데, 자원에 대한 명령의 범주는 결국 CRUD로 압축할 수 있다.

• C : Create. 자원을 생성
• R : Read. 자원의 정보를 읽기
• U : Update. 자원의 정보를 업데이트
• D : Delete. 자원의 삭제

각각 SQL언어의 Insert, Select, Update, Delete에 대응한다.HTTP는 CRUD를 위한 메서드를 이미 모두 포함하고 있다.

• C : POST
• R : GET
• U : UPDATE
• D : DELETE

추가적으로 몇개의 메서드들을 더 제공하는데, 여기에서는 설명하지 않겠다. CRUD를 명시해서 자원을 제어하는게 가능하다는 얘기가 되겠다.

RESTFUL API

RESTful API는 HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스다. 기본적으로 개발자는 HTTP 메서드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.

 기존의 웹 접근 방식과 RESTful API 와의 차이점

인터넷 게시판은 자원에 대한 CRUD를 모두 포함한다. 기존의 인터넷 게시판은 GET과 POST 만으로 CRUD를 모두 처리하기도 한다. 예컨데, 데이터를 읽는 것과 삭제하는 것 보다 GET 메서드를 이용하는 경우가 대부분이다. 또한 URI는 액션을 나타내지, 자원의 위치를 나타내지는 않는 경우가 많다. 좋게 말하자면 자유로운 거고, 나쁘게 말하자면 대중없다(명시적이지)않은 방식이다.두 가지 방식을 비교해 보자. java 게시판의 게시물에 대한 CRUD다.

RESTful 방식이 명확함을 알 수 있다. 제어하려는 자원이 무언지 명확하고, 자원에 대해서 어떤 행동을 할건지도 명확하다.

 

 

RESTful API 개발 원칙

 

자원을 식별할 수 있어야 한다.

URL 만으로 내가 어떤 자원을 제어하려고 하는지를 알 수 있어야 한다.

자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알수 있어야 한다는 이야기다.

실제 데이터, 그러니까 server측 데이터베이스에 저장되야하는 정보는 JSON이나 XML형태로 HTTP body 데이터로 전송하면 된다.

 

행위는 명시적이어야 한다.

REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제하지 않는다.

기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.

이것을 막는 규칙같은건 없지만, REST 아키텍처에는 부합하지 않는 방식으로 REST를 따른다고 할 수 없다.

REST에서 행위는 명시적이어야 한다. GET은 SELECT, POST는 CREATE

 

자기 서술적이어야 한다.

데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 애플리케이션을 실행해야 하는지를 알 수 있어야 한다. 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 이것은 자기 서술적이 아니다.예를 들어 동영상을 처리하는 웹 서비스의 경우, "application/video"만 보내는 것은 자기 서술적이 아니다. 동영상 정보를 알기 위해선는 원본 파일을 다운로드해서 분석해야 하기 때문이다. 자기 서술적이려면, 해상도, 코덱, 비트레이트, 자막파일의 위치, 플레이타임 등의 정보를 모두 포함해야 한다.

 

 

 

REST의 장점과 단점

REST의 장점을 정리했다.

1. 언어, 플랫폼에 독립적이다.
2. SOAP보다 쉽고 간단하다.
3. 학습이 용이하고, 개발도구가 거의 필요 없다.
4. (익숙한)웹기반의 설계
5. 개발 인프라가 탄탄하다. HTTP, URI 기반 서버, 클라이언트툴, 각종 라이브러리들은 완성단계의 기술이다. 개발자들은 하부구조에 신경쓰지 않고 비지니스 로직의 구현만 신경쓰면 된다.
6. 트랜드다. 예컨데 대세. 구글,야휴,트위터,facebook등의 기업들이 사용하고 있다. SOAP 기반으로 만들어

REST의 단점은 다음과 같다.

1. REST는 point-to-point 통신모델을 기반으로 한다. 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
2. REST는 URI, HTTP 를 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
3. HTTP에 (상당히)의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 자연스럽게 녹여내기가 쉽지 않을 수 있다. 대부분의 서비스가 웹으로 통합되는 상황에 비춰볼때 큰 단점은 아닌 것 같다.
4. CRUD의 4가지 메서드만 제공한다. 대부분의 일들을 처리할 수 있기는 한데, 4가지 메서드 만으로 처리하기엔 모호한 표현들이 있다.

 

 

 

 

참고

 

REST에 대하여