REST

WEB

웹의 가장 기본적인 기술은 HTTP, URI, HTML이다.

• HTTP : 웹의 자원(리소스)을 교환하기 위한 프로토콜
• HTML : 웹 페이지 포맷
• URI : 웹의 리소스를 가리키는 식별자

웹을 정보 시스템으로 본다면 하이퍼미디어 시스템, 분산 시스템이라는 두 가지 측면으로 볼 수 있다.

• 하이퍼미디어 시스템 : 하이퍼미디어란 텍스트, 이미지, 영상 등 다양한 미디어를 하이퍼링크(링크)로 연결해 구성한 시스템이다. 웹 페이지에는 다른 웹 페이지와 이미지, 동영상의 링크가 포함된다. 사용자는 브라우저를 통해 그 링크로 계속 이동하여 정보를 얻을 수 있다.
• 분산 시스템 : 웹의 자원은 한 곳에 모여있지 않고 전 세계에 퍼져있다. 즉 웹은 수 많은 서버로 구축된 분산 시스템이다.

REST의 등장

2000년 로이 필딩(Roy Fielding)이 웹이 어떻게 성공했고 어떻게 대규모 시스템으로 발전했는지 소프트웨어 아키텍처 관점에서 분석하고 하나의 아키텍처 스타일로 정리한 것이 REST(Representation State Transfer)이다. HTTP는 본래 하이퍼텍스트를 전송하기 위한 프로토콜이지만 REST 기반 아키텍처에서 HTTP가 전송하는 데이터는 리소스 상태의 표현이 된다. 아키텍처 스타일이란 아키텍처 설계 규정, 방식 또는 복수의 아키텍처의 공통된 성질, 규정등을 가리키는 말이다. 

 

REST의 등장 이후 REST는 웹의 아키텍처 스타일로 자리매김 하게 되었다. 따라서 우리가 웹 서비스 혹은 웹 API를 제공하는 웹 어플리케이션의 아키텍처를 만들때 가능한 REST를 따라야한다. 즉 RESTful하게 만들어야한다. (REST 아키텍처 스타일로 구현한 웹 서비스 혹은 웹 API를 RESTful이라 말한다.) 개별 웹 서비스마다 아키텍처가 다르다면 웹은 통일된 아키텍처를 유지할 수 없기 때문이다.

리소스

리소스는 웹상에 존재하는 이름을 가진 모든 정보를 말한다. 예를 들어 서울의 일기예보, 멘토르 출판사의 '웹을 지탱하는 기술' 페이지, 청량리역의 사진, 필자의 최근 북마크 등이 다 리소스이다. 그리고 리소스의 이름은 URI로 표현한다. URI을 통해 리소스를 식별하고 접근할 수 있다.

 

하나의 리소스는 여러 개의 URI를 가질 수 있다. 예를 들어 오늘의 날씨 정보는 아래 두개의 URI를 가질 수 있다.

http://weather.example.com/seoul/today
http://weather.example.com/seoul/2022-12-12

두 개의 URI은 같은 리소스를 가리키지만 첫 번째 URI은 오늘의 날씨 리소스를 가리키는 URI이므로 내일이 되면 다른 리소스를 가리킬 것이다.

 

리소스는 표현(Representation)과 상태(state)를 갖는다. 리소스 표현(Resource Representation)이란 리소스의 실제 데이터이다. 하나의 리소스는 여러 개의 표현을 가질 수 있다. 예를 들어 일기 예보 리소스는 HTML, 텍스트, PDF, 이미지 또는 한국어 형식 HTML, 영어 형식 HTML 등 여러 표현을 가질 수 있다. 

 

또한 리소스는 상태를 가진다. 예를 들어 일기 예보 리소스는 맑음이라는 상태였다가 흐림이라는 상태로 변할 수 있다. 리소스의 상태가 변하면 당연히 리소스의 표현도 변해야된다. 결국 HTTP의 get 메서드는 리소스를 얻는 메서드가 아닌 현재 상태의 여러 리소스 표현 중 하나를 얻는 것이다.

REST

REST는 클라이언트/서버 아키텍처에서 파생된 아키텍처이다. 클라이언트/서버 아키텍처 스타일에 몇 가지 제약을 더하면 REST라는 아키텍처 스타일이 된다. 아래의 제약들을 살펴보자.

• 클라이언트/서버 : 웹은 클라이언트와 서버가 HTTP 프로토콜로 통신하는 클라이언트/서버 아키텍처를 채용하고 있다. 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)하는 구조이다. 서버와 클라이언트를 분리함으로써 클라이언트는 UI에 집중하고 서버는 데이터 처리/저장에만 집중할 수 있다.

클라이언트/서버

 

• Stateless 서버 : 클라이언트 상태를 서버가 관리하지 않는다는 걸 뜻한다. 서버가 클라이언트 상태를 가지고 있지 않으면 그만큼 서버 측의 구현이 쉬워진다는 장점이 생긴다. 쿠키를 이용한 세션 관리와 같은 기술은 웹서버를 Statefull하게 만든다. 이러한 기술은 REST 관점에서 본다면 잘못되었지만 사용하지 않을 순 없기에 Stateless 서버의 이점을 버린다는 것을 이해한 후 최소한으로 사용해야한다.

클라이언트/스테이트리스 서버

 

• 캐시 : 한번 가져온 리소스를 다시 가져오지 않고 클라이언트에서 돌려쓰는 방법을 뜻한다. 캐시를 사용하면 서버와 클라이언트 사이의 통신량과 처리 시간을 줄일 수 있다. 단 오래된 캐시를 이용해 정보의 신뢰성이 떨어질 가능성도 있다.

클라이언트/캐시/스테이트리스 서버

 

• 유니폼 인터페이스 : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다. 예를 들어 HTTP 1.1에서는 GET과 POST등 8개의 HTTP 메서드로 리소스를 조작하도록 고정한다. 이러한 제약덕분에 인터페이스가 통일되면서 전체 아키텍처가 간결해지며 클라이언트와 서버간 종속성이 낮아진다. 즉 클라이언트는 어떤 서버든 8개의 메서드로 리소스 조작을 요청하고 서버는 어떤 클라이언트든 8개의 메소드 요청에 대해 리소스 조작을 수행하면 된다.

유니폼/클라이언트/캐시/스테이스리스 서버

 

• 계층화 시스템 : 유니폼 인터페이스의 이점 중 하나로 시스템 전체를 계층화 하기 쉽다. 웹 서비스에서는 서버와 클라이언트 간의 부하를 분산시키기 위한 로드 밸런스와 엑세스를 제어하는 프록시를 서버와 클라이언트 사이에 두기 쉽다. 프록시나 서버나 모두 동일한 HTTP 인터페이스를 사용하기에 클라이언트 입장에서 프록시나 서버를 구분할 필요가 없으며 반대로 서버 입장에서도 마찬가지다.

유니폼/계층화/클라이언트/캐시/스테이트리스 서버

 

• Code on Demand : 코드 온 디맨드는 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일이다. 자바스크립트, 플라스크 등이 여기에 해당한다. 아래의 그림이 REST 아키텍처 스타일이다.

(REST 아키텍처 스타일) = 유니폼/계층화/코드 온 디맨드/클라이언트/캐시/스테이트리스 서버

REST와 하이퍼미디어

웹은 하이퍼미디어 시스템이다. 링크를 따라가면서 정보를 얻는다. REST에서는 이러한 하이퍼미디어를 어플리케이션 상태 엔진으로 본다. 쉽게 말해 블로그 어플리케이션의 경우 '새 글을 작성하고 있다', '글을 수정하고 있다.','글을 읽고 있다' 등의 상태가 있으며 어플리케이션 상태는 하이퍼미디어의 링크를 따라감으로써 변한다. 때문에 하이퍼미디어는 어플리케이션의 상태엔진이다.

 

리소스를 링크로 연결해 하나의 어플리케이션(웹 앱)을 구성한다. 이러한 개념을 REST에서는 접속성(connectedness)이라 부르며 REST의 근간을 이루는 사상이다. 웹 앱은 리소스의 URI만 알면 다른 어플리케이션의 리소스를 간단히 재사용할 수 있다는 장점이 있다.

 

참고) 웹을 지탱하는 기술