[웹을 지탱하는 기술] chapter 03. REST 웹의 아키텍처 스타일

 

 

[목차]
chapter 01. 웹이란 무엇인가?
chapter 02. 웹의 역사
chapter 03. REST 웹의 아키텍처 스타일

 

01 아키텍처 스타일의 중요성

REST는 웹의 아키텍처 스타일. 아키텍처 스타일이 뭔데?

• (매크로) 아키텍처 패턴이라고도 함
• 복수의 아키텍처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가리키는 말
• 아키텍처를 설계할 때 참조할 수 있는 전형적 해결 방식 or 예제
• MVC(Model-View-Controller), 파이프 앤 필터(Pipe and Filter), 이벤트 시스템(Event System) 등이 있음

[1과목-3장-021] 아키텍처 패턴

• 디자인 패턴과는 다른 개념.
• 디자인 패턴은 ‘마이크로 아키텍처 패턴'이라고 하며, 아키텍처 스타일보다 입도(Granularity)가 작은 클래스 등의 설계 양식을 가리킨다.
• 아키텍처와 아키텍처 스타일은 별개
• 실제 시스템은 구체적인 아키텍처를 가지고 있다. 그 아키텍처를 설계할 때 아키텍처 스타일(아키텍처 설계 지침, 규정, 방식)을 적용한다. → 아키텍처 스타일은 시스템의 아키텍처를 결정할 때 나침반 역할

 

02 아키텍처 스타일로서의 REST

• 웹의 아키텍처 스타일은 REST이기도 하지만, 클라이언트-서버이기도 하다.
• → REST는 클라이언트-서버 구조에서 파생된 아키텍처 스타일이기 때문.
• 순수한 클라이언트-서버 아키텍처 스타일에 몇 가지 제약을 더한 것이 REST 아키텍처 스타일이다.
  • 여기서 제약은 아키텍처 스타일에 있어서 중요한 개념임
  • 소프트웨어 아키텍처는 복수의 컴포넌트를 조합해 구현하는데, 각 컴포넌트에 제약을 부과함으로써 전체적으로 협력하면서 동작하도록 함.
• 아키텍처 스타일은 특정한 구현이나 아키텍처가 아니다.
  • 구현에서 추상도를 한 단계 올린 것이 아키텍처.
  • 아키텍처에서 추상도를 한 단계 더 올린 것이 아키텍처 스타일추상화 레벨 웹에서의 예 

    아키텍처 스타일	REST
    아키텍처	브라우저, 서버, 프록시, HTTP, URI, HTML
    구현	Apache, Firefox, Internet Exploerer

• 개인이 만드는 각 웹 서비스와 웹 API에서도 REST의 규약을 지키는 것이 중요하다.
  • 개별 웹 서비스가 전체의 조화를 무너뜨리면, 전체가 통일된 아키텍처 스타일을 지킬 수 없기 때문
  • REST는 웹 전체의 아키텍처 스타일이면서, 개별 웹 서비스와 웹 API의 아키텍처 스타일이어야 한다.

 

03 리소스

REST를 이해하기 위해서는 리소스(Resource)에 대한 이해가 반드시 필요하다.

• 리소스를 한마디로 설명하면, ‘웹상에서 존재하는 이름을 가진 모든 정보'다.
• 리소스가 이름을 가진다? → 어떤 리소스를 다른 리소스와 구별하는데 리소스의 이름을 사용하겠다는 것
• 리소스의 이름이란 URI를 말한다.
  • URI를 이용함으로써, 프로그램은 리소스가 표현하는 정보에 접근할 수 있다.
  • ex) 서울의 일기 예보 정보는 이 URI로 접근할 수 있다 → http://weather.naver.com/rgn/cityWetrWarea.nhn?cityRgnCd=CT001000
• 리소스의 ‘어드레스 가능성(Addressability)’
  • 리소스의 어드레스 가능성은 리소스를 간단히 가리킬 수 있는 성질을 의미
  • URI는 구조를 가지고 있기 때문에 특정 파일에 접근할 방법을 한 줄로 제공한다는 특징을 가짐
• 1개의 리소스는 복수의 URI를 가질 수 있다.
  • 하나의 리소스에 URI를 여러 개 붙여 두면, 클라이언트가 리소스에 접근하기 쉬워진다.
  • 반면, 어느 것이 정식 URI인지 알기 힘들다는 결점도 가짐.
• 리소스의 표현과 상태
  • 서버와 클라이언트 간에 실제로 리소스를 주고받을 때는 어떤 구체적인 데이터를 서로 송신
  • 그 데이터를 ‘리소스 표현(Resource Representation)’이라고 부름
  • 하나의 리소스는 복수의 표현을 가질 수 있다. → HTML, 텍스트, PDF, 이미지 ...
  • 리소스에는 상태라는 것이 존재한다. → 리소스의 상태가 변하면 표현도 변함

URI vs URL?

• URI는 통합 자원 식별자(Uniform Resource Idendifier)
• URL은 자원이 실제로 존재하는 위치(Uniform Resource Locator) + 고유 식별자로서의 역할

→ URI가 URL을 포함하는 개념

URI랑 URL 차이점이 뭔데? | 찰스의 안드로이드

 

04 스타일을 조합하여 REST를 구성한다.

REST는 복수의 아키텍처 스타일을 조합하여 구축한 복합 아키텍처 스타일이다.

• 클라이언트-서버 : 유저 인터페이스와 처리를 분리한다.
  • 웹은 HTTP를 이용해 클라이언트와 서버가 서로 통신하는 아키텍처 스타일을 채용
  • 클라이언트가 요청하면 서버는 응답하는 구조
• Stateless 서버 : 서버 측에서 애플리케이션의 상태를 가지지 않는다.
  • stateless란 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것을 의미
  • 서버가 상태를 가지지 않게 되면, 구현을 간략화할 수 있다는 장점이 있다.
  • Cookie를 사용한 세션 관리는 HTTP를 stateful하게 만드는 것으로, REST 관점으로는 잘못된 확장임.
• 캐시 : 클라이언트와 서버의 통신횟수와 양을 감소시킨다.
  • 캐시는 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓰는 방식.
  • 통신량을 줄여 네트워크 대역의 이용과 처리시간 축소하고, 더욱 효율적으로 처리할 수 있음
  • 캐시의 신선도가 중요함. 오래된 캐시를 이용하면 정보의 신뢰성이 떨어질 가능성이 있음.
• 유니폼 인터페이스 : 인터페이스를 고정한다.
  • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
  • 예) HTTP 1.1에서는 8개의 메서드만 정의되어 있고, 확장할 수 없도록 함
  • 인터페이스의 유연성에 제약을 가함으로써 전체적인 아키텍처가 간결해짐
• 계층화 시스템 : 시스템을 계층별로 분리한다.
  • 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일
  • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
  • 확장성과 보안성을 향상시킬 수 있다.
• 코드 온 디맨드 : 프로그램을 클라이언트에 다운로드하여 실행한다.
  • 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일
  • 예) JavaScript, Flash, Java
  • 클라이언트를 차후에 확장할 수 있다는 장점을 가짐
  • 네트워크 통신에서의 프로토콜 가시성이 저하되는 결점이 있음. → 가시성이 저하된다는 것이 어떤 의미지?? (리소스와 코드가 섞이기 때문에 주고 받는 메시지에 대한 가독성이 떨어진다는건가?)
  • 로이필딩은 코드 온 디맨드를 옵션으로 다뤘음

앞선 6가지 스타일을 모두 추가한 아키텍처 스타일을 ‘유니폼/계층화/코드 온 디맨드/클라이언트/캐시/스테이트리스 서버(Unifrom Layered Code on Demand Client Cache Stateless Server)’라 하고, 줄여서 ULCODC$SS라고 한다. REST는 이 6가지를 조합한 아키텍처 스타일을 가리킨다.

REST는 아키텍처 스타일이므로 실제로 시스템을 설계할 때는 그 시스템의 아키텍처를 만들어야 한다.

소프트웨어와 시스템의 설계에서는 아키텍처 스타일의 이상과 타협해야만 하는 부분도 존재한다. REST에 기초한 아키텍처를 구축할 경우라도 몇 가지 스타일을 제외하더라도 상관없다.

REST 아키텍처 스타일이라는 이상을 염두에 두면서 실제로 동작하고 가치를 제공할 수 있는 시스템을 만드는 것이 중요하다.

REST 스타일의 대부분을 제외해야만 하는 경우에는 REST를 고집할 필요없다. 그런 시스템에는 보다 적합한 다른 아키텍처 스타일이 존재하기 때문이다. 예를 들어, 서버를 거치지 않고, 피어(Peer) 사이에서의 통신이 필요한 경우는 P2P 아키텍처 스타일이 유리하다.

 

05 REST의 2가지 측면

REST와 하이퍼미디어

• 보통 웹을 사용할 때는 링크를 따라가면서 다양한 리소스에 접근하게 된다.
• 하이퍼미디어의 기본 기능인 링크를 따라가는 작업을 거치면서 전체적으로는 하나의 애플리케이션이 실현된다.
• 웹이 가진 이 특징을 REST에서는 애플리케이션 상태 엔진으로서의 하이퍼미디어(Hypermedia as the engine of application state)라고 한다.
  • 애플리케이션 상태란 애플리케이션 이용자가 가지는 상태를 의미
  • 애플리케이션 상태는 하이퍼미디어의 링크를 따라가는 작업에 의해 변화하기 때문에 하이퍼미디어를 애플리케이션 상태 엔진이라고 부름
• 하이퍼미디어를 이용한 애플리케이션은 리소스의 URI만 알면 애플리케이션이 제공하고 있는 리소스를 다른 애플리케이션에서도 간단히 재사용할 수 있다는 장점이 있음.
• 리소스를 링크로 연결하여 하나의 애플리케이션을 구성한다는 개념은 REST의 근간을 이루는 사상. 접속성(Connectedness)라고도 불림

REST와 분산 시스템

성능 저하 부분

• RPC와 CORBA, DCOM 등의 분산 오브젝트에서는 함수나 메서드 단위로 서버 쪽의 처리를 호출함
• 네트워크를 통한 함수 호출은 오버헤드가 심하기 때문에 호출 횟수가 많아질수록 시스템 전체 성능의 저하를 가져옴. 회피방법이 있지만 구현이 쉽지 않음.
• RPC와 분산 오브젝트는 서버마다 다른 인터페이스를 가지고, 개별 인터페이스는 프로그램 라이브러리의 인터페이스를 기반으로 개발하는 경우가 많기 때문.
• 그에 비해 REST에 기초한 웹 서비스에서는 링크를 이용하여 애플리케이션을 실현함.
• 리소스는 그 자체로 의미를 가진 하나의 데이터이며, RPC 함수에 의해 주고받는 데이터보다 입도가 큼.
• 때문에 링크를 따라 애플리케이션의 상태를 변화시키는 편이 전체적인 성능 저하를 억제할 수 있음

호환성 부분

• RPC와 분산 시스템에서는 기능을 추가해 버전 업 할 때마다 메서드가 늘어나거나 메서드의 인수와 반환값이 바뀌어 API 호환성이 상실됨. 기존의 클라이언트를 모두 동시에 변경해야하는데, 웹과 같은 대규모 시스템에서는 비현실적
• REST에 기초한 웹에서는 유니폼 인터페이스에 의해 인터페이스가 고정되어 있기 때문에 HTTP를 구현한 클라이언트라면 호환성 문제가 발생하지 않음.
• 게다나 HTTP에서는 인터페이스의 하위 호환성을 보증하고 있음.

 

06 REST의 의미

REST는 웹 전체의 아키텍처 스타일. 웹은 REST라는 분산 네트워크 시스템을 위한 이론이 있었기에 이만큼 성공했다고 말할 수 있다.

우리들이 만드는 웹 서비스나 웹 API는 웹을 구성하는 일부분이기 때문에, RESTful한 서비스와 API를 만들면 웹은 전체적으로 좋은 환경이된다.

이 장 이후로는 RESTful하게 설계하기 위해서는 어떻게 해야하는지에 대해 알아본다.