세계적 규모의 하이퍼 미디어이자 분산 시스템인 웹, 웹은 가장 성공한 시스템이다. 이 거대한 시스템이 어떻게 동작하고 있는 것일까 ? 그것을 알기 위해 웹의 설계사상인 REST에 대하여 알아보자
00 아키텍처 스타일의 중요성
REST는 웹의 아키텍처 스타일이다. 아키텍처 스타일은 아키텍처 패턴이라고도 불리며, 복수의 아키텍처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가르킨다.
아키텍처 스타일에는 MVC, 파이프 앤 필터, 이벤트 시스템등이 있다.
디자인과 디자인 패턴이 다르듯 아키텍처와 아키텍처 스타일은 별개이다. 디자인 패턴 책에서 소프트웨어의 설계 자체는 다루지 않는다. 패턴을 학습하고 설계에 적용 하여 실제로 소프트웨어가 만들어지면 설계가 비로소 구현이 되는 것이다.
아키텍처도 마찬가지인데, 아키텍처 설계 지침, 방식 즉, 스타일을 적용함으로 시스템의 아키텍처를 결정 할 때 나침반이 되는 것이 아키텍처 스타일이다.
01 아키텍처 스타일로서의 REST
REST는 수많은 아키텍처 스타일 중에서도 네트워크 시스템의 아키텍처 스타일이다. 네트워크 시스템 아키텍처 스타일로 가장 유명한 것은 Client/Server이다. 그리고 웹은 Client/Server이기도 하다.
즉, 웹의 아키텍처 스타일이 REST이기도 하지만, Client/Server 이기도 하다는 말이다. 이게 도대체 무슨 말인가 ?
사실 REST가 Client/Server구조에서 파생된 것이다. 순수한 Client/Server에 몇 가지 제약을 더해가면 REST라는 아키텍처 스타일이 되는 것이다.
제약은 아키텍처 스타일에 있어서 중요한 개념이다. 일반적으로 소프트웨어 아키텍처는 복수의 컴포넌트를 조합하여 구현하는데, 각각 컴포넌트가 따로따로 움직인다면 동작하지 않을 것이다. 그래서 각 컴포넌트에 제약을 부과한다. 그 결과, 전체적으로 각 컴포넌트가 협력하면서 동작하게 된다.
아키텍처 스타일은 특정한 구현이나 아키텍처가 아님을 유의해야 한다.
웹의 아키텍처 구현은 REST 아키텍처 스타일을 따르고 있지만, 웹 이외의 아키텍처와 구현도 생각해 볼 수 있다. 구현에서 추상도를 한 단계 올리면 아키텍처이고, 여기서 한번 더 올린 것이 아키텍처 스타일이다. 다만 REST라고 하면 웹의 아키텍처 스타일을 가르키는 경우가 많아. REST의 구현 예로 웹을 이용하려고 한다.
REST는 웹 전체의 아키텍처 스타일이고 하며 개별 웹 서비스와 웹 API의 아키텍처 스타일이기도 하다. 웹 서비스와 웹 API에서도 REST의 규약을 지키는 것은 중요하다. 전체로 통일된 아키텍처 스타일을 지키기 위함이다.
02 리소스
REST에 있어서 중요한 개념의 하나가 리소스이다. REST를 이해하기 위해 리소스에 대한 이해가 반드시 필요하다.
리소스란 "웹상에 존재하는 이름을 가진 모든 정보"이다. 예를 들면
- 서울의 일기예보
- 웹을 지탱하는 기술 페이지
- 서울역의 사진
- velog.io/kanamycine의 시리즈 북마크
위에 예로 든 것들이 모두 다 리소스다.
리소스 명칭으로서의 URI
리소스의 이름이란 URI를 말한다. 좀 전의 리소스는 각각 다음과 같은 URI로 식별할 수 있다.
-
서울의 일기예보
http://weather.naver.com/rgn/cityWetrWarea.nhn?cityRgnCd=CT001000 -
멘토르 출판사의 '웹을 지탱하는 기술' 페이지
http://mentorbooks.dothome.co.kr/IT/4864
리소스의 어드레스 가능성
지금은 당연시 된 웹의 URI이지만, 웹과 URI의 발명은 획기적이라고 평가되고 있다. 웹과 URI의 발명 이전에는 큰 파일을 어딘가의 서버에 저장해두고 그 장소를 친구에게 메일로 알려 줄 경우 다음과 같이 이메일을 쓸 수 밖에 없었다.
요즘은 상상하기 힘든 내용의 메일인, URI가 있는 현재는 특정 파일에 접근하는 방법을 일일히 설명할 필요가 없어졌고, 단순히 'ftp://example.com/public/data/example_file.gz'라는 URI 한 줄로 적어 액세스 하도록 하면 충분하다.
또한 위 메일을 사람이 읽고 이해하는 것은 간단하지만 프로그램으로 해석하여 파일을 다운로드하는 것은 매우 어려운 작업이다. 자연어로 기술되어있는 FTP 서버와 로그인 정보, 게다가 서버 내의 디렉터리 구조를 추출하지 않으면 안 되기 때문이다.
URI는 구조를 가지고 있기 때문에 프로그램에서 간단히 처리할 수 있어서 이 문제를 단번에 해결했다.
URI가 지니고 있는 리소스를 간다히 가리킬 수 있는 성질을 가리켜 어드레스 가능성이라고 한다. 리소스를 어드레스 가능한 상태, 즉 이름이 붙어있고 적절한 수단으로 접근할 수 있는 상태로 만들면, 프로그램을 만들기가 아주 쉬워진다.
복수의 URI를 가진 리소스
1개의 리소스는 복수의 URI를 가질 수 있다. 예를 들자면 오늘이 2010년 1월 1일이라고 하면
2011년 1월 1일 시점에서는 이 2개의 URI는 같은 리소스를 가르키지만, URI의 의미는 다르다. 첫 번째 예는 '오늘의 서울 날씨'를 가르키고, 두 번째 예는 '2011년 1월 1일의 서울 날씨'를 가르키는 URI이기 때문이다.
첫 번째 예는 날짜가 바뀌면 가르키는 리소스가 변하게 된다. 하나의 리소스에 URI를 여러개 붙이면, 클라이언트가 리소스에 접근하기 쉬워진다. 그 반면, 어느 것이 정식 URI인지 알기 힘들다는 결점도 가지게 된다.
리소스의 표현과 상태
리소스는 웹상에 존재하는 정보라는 추상적인 개념이다. 서버와 클라이언트 간에 리소스를 주고 받을 땐, 어떤 구체적인 데이터를 서로 송신한다. 서버와 클라이언트 사이에 주고 받는 데이터를 Resource Representation이라고 한다.
하나의 리소스는 복수의 표현을 가질 수 있다. 예를 들어 일기예보 리소스는 HTML 형식은 물론, 텍스트 형식으로도 PDF나 이미지로 표현할 수 있다. 리소스의 복수 표현에 개별 URI를 부여해도 좋고, HTTP 구조를 이용해 하나의 URI로 복수 표현을 반환할 수 있다.
또한 리소스에는 '상태'라는 것이 있는데, 시간의 경과에 따라 리소스의 상태가 변하면 그 표현도 변한다. 일기예보의 예를 들면, 현재의 예보가 '맑음'이라도 몇시간 후에는 '흐림'으로 변할 지도 모른다.
03 스타일을 조합하여 REST를 구성한다
이것으로 REST에서 중요한 리소스에 대한 설명을 마쳤다. 여기부터는 REST 아키텍처 스타일이 과연 어떻게 구성 되어 있는지 살펴볼 것이다.
REST는 복수의 아키텍처 스타일을 조합하여 구축한 복합 아키텍처 스타일이다. 이제부터 Client/Server 이외의 아키첵터 스타일을 추가하고 제약을 부과하며 REST를 구축해보자
Client/Server
웹은 HTTP라는 프로토콜을 이용하여 클라이언트와 서버가 서로 통신하는 Client/Server 아키텍처 스타일을 채용하고 있다. 즉, 클라이언트가 서버로 요청을 보내면 서버는 클라이언트에 대해 응답을 돌려준다.
Client/Server의 이점은 단일 컴퓨터 상에서 모든 것을 처리하는 것이 아니라, 클라이언트와 서버로 분리해서 처리할 수 있다는 점이다.
이렇게 되면 현재의 웹이 PC뿐만아니라 휴대전화나 게임기를 통해서도 접속할 수 있는 멀티 플랫폼으로 구성할 수 있다.
또한, UI는 클라이언트에서 담당하기 때문에 서버는 데이터 스토리지로서의 기능만을 제공하면 된다. 복수의 서버를 조합해 확장함으로써 가용성을 올릴 수 있게 된다.
스테이트리스 서버
Client/Server에 최초로 추가할 아키텍처 스타일은 스테이트리스 서버이다. 여기서 말하는 스테이트리스란, 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것을 의미한다.
서버가 애플리케이션의 상태를 가지지 않게 되면, 그만큼 서버 측의 구현을 간략화 할 수 있다는 장점이 있다. 간략하게 구현된 서버는 클라이언트로부터의 요청에 응답한 뒤 바로 서버의 자원을 해체할 수 있다.
하지만 현실적으로는 스테이트리스가 아닌 웹 서비스와 웹 API가 많이 있다. 특히 HTTP를 스테이트풀하게 만드는 것은 Cookie를 사용한 세션 관리인데, REST의 과점에서 본다면, Cookie를 사용한 세션관리는 HTTP의 잘못된 확장이다. 다만 REST 기준으로 잘못되었다고 해서 Cookie를 사용한 폼 인증을 그만 둘수 없는 것도 현실이다.
Cookie는 스테이트리스 서버의 이점을 버린다는 것을 이해한 후에 최소한으로 이용하는 것이 좋다.
클라이언트/서버에 스테이트리스성을 도입하면, 아키텍처 스타일은 '클라이언트/스테이트리스 서버'가 된다.
캐시
다음은 캐시다. 캐시란, 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓰는 방식이다. 캐시의 장점은 서버와 클라이언트 사이의 통신량을 줄여주고, 네트워크 대역의 이용과 처리시간을 축소해준다. 더 효율적으로 처리할 수 있다는 것인데, 오래된 캐시를 이용해 정보의 신뢰성이 떨어질 가능성도 있다. 캐시를 추가한 아키텍처 스타일은 '클라이어트/캐시/스테이트리스/서버'라고 한다.
유니폼 인터페이스
다음으로 살펴볼 아키텍처 스타일은 유니폼 인터페이스다. 유니폼 인터페이스는 URI로 지정한 리소스에 대한 조작을 통일 되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
예를 들어, HTTP 1.1에서는 GET과 POST 등 8개의 메서드만 정의되어 있고, 보통은 이 이상 늘어나지 않는다. 메서드가 8개로 고정되어 확장할 수 없는 것은 일반적인 기준에서 생각할 때 엄격한 제약으로 느껴지지만, 인터페이스의 유연성에 제약을 가함으로써 아키텍처가 간결해진다. 또한 인터페이스를 통일함으로써 클라이언트와 서버 구현의 중립성이 향상된다.
유니폼 인터페이스는 REST를 가장 특징짓는 아키텍처 스타일이다. 유니폼 인터페이스를 추가한 아키텍처 스타일을 '유니폼/클라이언트/캐시/스테이트리스/서버 라고 한다.
계층화 시스템
유니폼 인터페이스의 이점 가운데 하나로, 시스템 전체를 계층화하기 쉽다는 점을 들 수 있다. 예를 들면 웹 서비스에서 서버와 클라이언트 간의 로드 밸런서를 설치하여 부하를 분산시키거나, 프록시를 설치하여 액세스를 제어한다. 클라이언트 측에서 보면 서버나 프록시 모두 동일한 인터페이스로 접속할 수 있기 때문에 접속할 곳이 서버에서 프록시로 바뀐 것을 신경 쓸 필요가 없다. 각 컴포넌트 간의 인터페이스를 HTTP로 통일하고 있어서 실현될 수 있다.
또한, 레거시 시스템 등 HTTP의 인터페이스를 구현하지 않는 시스템에서도 레거시 시스템 앞단에 웹 어플리케이션 서버를 끼워 넣고 HTTP의 인터페이스를 가지게 함으로써, 브라우저 등의 클라이언트와 접속할 수 있게 된다.
이와 같이 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일을 계층화 시스템이라고 한다.
계층화 시스템을 추가한 아키텍처 스타일을 '유니폼/계층화/클라이언트/캐시/스테이트리스 서버'라고 부른다.
코드 온 디맨드
코드 온 디맨드는 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일이다. 예를 들어 Javascript나 Flash, java 애플릿 등이 여기에 해당 된다.
장점은 클라이언트를 차후에 확장할 수 있다는 것이다. 물론, 결점은 있는데, 네트워크 통신에서의 프로토콜 가시성이 저하된다는 것이다. HTTP라는 애플리케이션 프로토콜에 따라 통신하고 있는 동안은 통신의 의미와 접근할 리소스가 명백하다. 그러나 코드 온 디맨드로 프로그램을 다운로드하여 클라이언트에서 실행해 버리면 애플리케이션 프로토콜의 가시성은 저하된다.
REST = ULCODC$SS
클라이언트/서버에 코드 온 디맨드까지 추가한 복잡한 아키텍처 스타일을 필딩은 REST라고 이름을 붙였다.
REST 아키텍처는 스타일이므로 실제로 시스템을 설계할 때는 그 시스템의 아키텍처를 만들어야만한다. REST에 기초한 아키텍처를 구축할 경우라도 REST를 구성하는 스타일 중 몇 가지를 제외하여도 상관 없다.
예를 들어, 쿠키 정보 등을 통해 세션에 값을 저장하도록 하여 스테이트풀 하지만 URI 형식 등은 REST의 제약에 따르는 아키텍처도 생각해 볼 수 있다.
이상을 염두에 두고 실제로 동작하고 가치를 제공할 수 있는 시스템을 만드는 것이 중요하다.
04 REST의 2가지 측면
지금까지는 REST의 특징을 소개했는데, 이번에는 REST와 하이퍼 미디어, REST 분산 시스팀의 관계를 살펴보면서, 하이퍼 미디어가 REST에 어떻게 영향을 미치고 있는지, 웹이 어떻게 분산 시스템으로서 성공했는지 알아보자.
REST와 하이퍼미디어
보통 우리가 사용하는 북마크를 예로 들어보자. 자신의 북마크를 열람하고, 즐겨 찾는 유저의 북마크로 가거나, 마음에 드는 북마크를 자신의 북마크에 넣는 작업들이 있겠다.
이 작업들의 최소 단위는 '웹상의 리소스들이 가지는 링크를 따라가는 것'이다. 하이퍼 미디어의 기본 기능인 링크 따라가기 작업을 몇번 거치면서, 소셜 북마크라는 하나의 애플리케이션이 실현된다.
웹이 가진 이 특징을 REST에서는 애플리케이션 상태 엔진으로서의 하이퍼미디어라고 한다. 애플리케이션 상태란, 예를 들어 소셜 북마크 애플리케이션의 이용자가 가지는 상태를 말한다. '북마크 목록을 표시하고 있다.' '새로운 북마크를 추가하고 있다.' 등이 구체적인 예이다.
어플리케이션 상태는 하이퍼미디어의 링크를 따라가는 작업에 의해 변한다. 때문에 하이퍼미디어가 애플리케이션 상태 엔진이라고 불리는 이유다.
이러한 애플리케이션에는 리소스의 URI만 알면 어떤 애플리케이션이 제공하고 있는 리소스를 다른 애플리케이션에서도 간단히 재사용할 수 있다는 장점을 가진다. 뉴스 사이트나 개발자용 도큐먼트 같은 다른 목적의 애플리케이션 리소스를 북마크 함으로써 리소스의 URI를 소셜 북마크에서 재이용한다고 생각할 수 있다.
리소스를 링크로 연결하여 하나의 애플리케이션을 구성한다는 개념은 REST의 근간을 이루고 있는 사상이다. 이 개념은 '접속성' 이라고도 불린다.
REST와 분산 시스템
RPC, CORBA, DCOM 등의 분산 오브젝트에서는 함수나 메서드 단위로 서버 쪽의 처리를 호출한다. 네트워크를 통한 함수 호출은 동일 프로세스 내의 함수 호출과는 비교도 되지 않을만큼 오버헤드가 심하다. 호출 횟수가 많아질수록 시스템 전체 성능의 저하를 가져온다.
인터페이스의 입도를 크게하고 호출 횟수를 줄임으로써 회피 할 순 있지만 구현은 어렵다.(서버마다 다른 interface, 개별 interface는 프로그램 라이브러리의 인터페이스를 기반으로 개발하는 경우가 많아서)
그에 비해 REST에 기초한 웹 서비스에서는 링크를 이용하여 애플리케이션을 실현한다. 리소스는 그 자체로 의미를 가진 하나의 데이터이고, RPC 함수에 의해 주고받는 데이터보다 입도가 크다. 그러므로 링크를 따라 애플리케이션의 상태를 변화시키는 편이 전체적인 성능 저하를 억제 할 수 있다.
또 RPC와는 다르게 유니폼 인터페이스에 의해 인터페이스가 고정되어 있어서 호환성 문제가 발생하지 않는다.
리소스에 적용할 수 있는 HTTP 메서드가 항상 고정되어 있어서 HTTP를 구현한 클라이언트라면 동일하게 접속이 가능하다.
05 REST의 의미
REST는 웹 전체의 아키텍처 스타일이다. 웹은 REST라는 분산 네트워크 시스템을 위한 이론이 있었기에 이만큼 성공할 수 있었다. 우리들이 만드는 웹 서비스나 웹 API는 웹을 구성하는 일부분이다. 개별 웹 서비스와 웹 API가 RESTful이라면 웹은 전체적으로 더 좋아진다.
