layout: post
title: "웹을 지탱하는 기술 스터디 - Chapter3"
date: 2022-03-05T00:00:00-00:00
author: sangyeop
categories: Sproutt-2nd

---

새싹 개발 서적 스터디 - 웹을 지탱하는 기술 Chapter03

Chapter 03. REST 웹의 아키텍처 스타일

아키텍처 스타일의 중요성

REST는 웹의 아키텍처 스타일이다.

아키텍처 스타일이란? : 복수의 아키텍처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가리키는 말

디자인과 디자인패턴이 다르듯이, 아키텍처와 아키텍처 스타일은 다르다.

실제 시스템은 구체적인 아키텍처 스타일을 가지고 있는데, 아키텍처를 설계할 때 마구잡이로 만드는 것이 아니라 설계 지침, 규정, 방식 등 아키텍처 스타일을 적용한다. 즉 시스템의 아키텍처를 결정할 때 나침반이 되는 것이 아키텍처 스타일이다.

아키텍처 스타일로서의 REST

REST는 수많은 아키텍처 스타일 중에서 네트워크 시스템의 아키텍처 스타일에 해당한다. 가장 유명한 것에는 웹에 해당하는 클라이언트/서버 아키텍처 스타일이 있다.

즉 웹은 REST이기도 하면서 클라이언트/서버 아키텍처 스타일이기도 하다. 이게 무슨 의미일까? 사실 REST는 클라이언트/서버 구조에서 파생된 아키텍처 스타일이다. 순수 클라이언트/서버 아키텍처 스타일에 몇 가지 제약 사항이 더해진 것이 REST 아키텍처가 되었다.

제약은 아키텍처 스타일에 있어서 중요한 개념이다. 소프트웨어 아키텍처는 여러개의 컴포넌트가 조합되어 구현되어진다. 이 컴포넌트들이 제 각각 동작하는 것이 아니기 때문에 각 컴포넌트에 제약이 부과되어져서, 컴포넌트끼리 협력하며 동작할 수 있게 된다.

아키텍처 스타일, 아키텍처, 구현은 어떻게 다를까?

• 구현
  • Apache, Firefox, Internet Explorer
• 아키텍처
  • 구현에서 추상도를 한 단계 올린 것
  • 브라우저, 서버, 프록시, HTTP, URI, HTML
• 아키텍처 스타일
  • 아키텍처에서 추상도를 한 단계 올린 것
  • REST

REST는 웹 전체의 아키텍처 스타일 이면서, 개별 웹 서비스와 웹 API의 아키텍처 스타일이기도 하기 때문에, 개개인이 만드는 각 웹 서비스와 웹 API에서도 REST 규약을 지키는 것이 중요하다.

리소스

REST에 있어서 리소스는 중요한 개념이다. 리소스에는 어떤 것들이 있을까?

리소스의 예

• 서울 일기예보
• 청량리역 사진
• 멘토르 출판사의 '웹을 지탱하는 기술' 페이지

이렇듯 뤱 상에 존재하는 이름을 가진 모든 정보가 리소스가 된다.

리소스 명칭으로서의 URI

리소스의 이름이란 곧 URI를 의미한다.

• 서울 일기예보

  http://weather.naver.com/rgn/cityWetrWarea.nhn?cityRgnCd=CT001000

• 생략

리소스에 대해서 정리해보면 다음과 같다

정리

• 리소스란 웹 상의 정보이다
• 전 세계의 무수한 리소스는 각각 URI로 의미 있는 이름을 가진다.
• URI를 이용함으로써, 프로그램은 리소스가 표현하는 정보에 접근할 수 있다.

리소스의 어드레스 가능성

어드레스 가능성이란 ? : URI가 지니고 있는 리소스를 간단히 가리킬 수 있는 성질, 즉 제대로 이름이 붙어있고 적절한 수단으로 접근할 수 있는 상태

이는 아래와 같은 예시를 URI 한 줄로 간단하게 바꿀 수 있음을 의미한다.

전에 말씀 하신 파일을 ftp.example.com에 두었습니다.
디렉토리는 /public/data이고, 파일명은 sample_file.gz입니다. 이 서버는 anonymous FTP 이므로 익명으로 로그인해주세요.

-> ftp://example.com/public/data/sample_file.gz

복수의 URI를 가진 리소스

1개의 리소스는 복수의 URI를 가질 수 있다.

http://weather.example.com/seoul/today
http://weather.example.com/seoul/2011-01-01

같은 리소스지만 두 URI는 서로 다른 의미를 갖는다. 이 처럼 하나의 리소스에 여러개의 URI를 붙여 놓으면, 클라이언트가 리소스에 접근하기가 용이해진다,

리소스의 표현과 상태

리소스는 '웹 상에 존재하는 정보' 라는 추상적인 개념이다. 실제로 서버와 클라이언트간에 리소스를 주고 받을때는 구체적인 데이터로 송신하게 되는데, 이 데이터를 리소스 표현(Resource Representation)이라고 한다.

하나의 리소스는 여러개의 표현을 가질 수 있다. 하나의 예를 들어 보자면 일기예보는 HTML, 텍스트, PDF, 이미지 등으로 표현이 될 수 있음을 의미한다.

또 리소스는 상태를 갖는다. 상태가 변화하면 표현도 변화한다. 오늘의 날씨가 '맑음' 이더라도 내일은 '흐림'으로 바뀔 수 있음을 의미한다.

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

REST 아키텍처 스타일은 다음으로 구성되어 있다

• 클라이언트/서버

  웹은 HTTP라는 프로토콜을 이용해 통신하는 클라이언트/서버 아키텍처 스타일을 채용한다.

  • 클라이언트 - 유저 인터페이스 담당
  • 서버 - 데이터 스토리지 담당

• 스테이트리스 서버

  스테이트리스란? : 클라이언트의 애플리케이션 상태를 서버에서 관리하는 않는 것

  서버가 애플리케이션 상태를 가지지 않으면, 서버 측 구현이 간단해지는 장점이 있다. 하지만 현실적으로는 HTTP를 스테이트풀 하게 만드는 Cookie를 사용한 세션관리가 많이 사용된다. 때문에 Cookie는 스테이트리스 서버의 이점을 버린다는 것을 이해하고 최소한으로 이용하도록 한다.

  스테이트리스 서버를 도입한 아키텍처 스타일은 클라이언트/스테이트리스 서버 아키텍처 스타일 이라고 부른다.

• 캐시

  캐시란? : 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓰는 방식

  한번 가져온 리소스를 돌려쓰기 때문에, 서버와 클라이언트 사이의 통신량을 줄여 더욱 효율적으로 처리할 수 있다는 장점이 있다. 반면 오래된 캐시를 이용할 경우 정보의 신뢰도가 떨어질 수 있다는 단점이 있다.

  캐시를 추가한 아키텍처 스타일은 클라이언트/캐시/스테이트리스 서버 아키텍처 스타일 이라고 부른다.

• 유니폼 인터페이스

  유니폼 인터페이스란? : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

  HTTP 1.1에서는 GET,POST 등 8개 메서드로만 제약되어있다. 이렇게 함으로써 전체적인 아키텍처가 간결해지고, 통일성을 가함으로써 클라이언트와 서버 구현의 중립성이 향상된다.

  유니폼 인터페이스를 추가한 아키텍처 스타일을 유니폼/클라이언트/캐시/스테이트리스 서버 라고 부른다.

• 계층화 시스템

  계층화 시스템이란? : 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일

  유니폼 인터페이스의 이점 중 하나는 시스템 전체를 계층화 하기 쉽다라는 점이다. 예를 들면 서버와 클라이언트 간에 프록시를 설치해 엑세스를 제어하고, 로드 밸런서를 설치해 부하를 줄이는 경우 등이 있다. 이는 서버와 프록시 등 각 컴포넌트 간에 인터페이스를 HTTP로 통일하였기 때문에 실현 가능 했다.

  계층화 시스템을 추가한 아키텍처 스타일을 유니폼/계층화/클라이언트/캐시/스테이트리스 서버 라고 부른다.

• 코드 온 디맨드

  코드 온 디맨드란? : 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일

  JavaScript, Flash, Java 애플릿 등이 여기에 해당한다.

  장점

  • 클라이언트를 차후에 확장 가능 ( 새로운 기능을 계속 추가할 수 있다 )

  단점

  • 네트워크 통신에서 프로토콜 가시성이 저하된다.

  코드온 디맨드를 추가한 아키텍처 스타일을 유니폼/계층화/코드 온 디맨드/클라이언트/캐시/스테이트리스 서버 라고 부른다.

• REST = UNCODC$SS

  위에서 설명한 아키텍처 스타일들을 필딩은 REST라고 부르기로 하였다.

  • 클라이언트 서버

    유저 인터페이스와 처리를 분리한다.

  • 스테이트리스 서버

    서버 측에서 애플리케이션의 상태를 가지지 않는다.

  • 캐시

    클라이언트와 서버의 통신횟수와 양을 감소시킨다.

  • 유니폼 인터페이스

    인터페이스를 고정한다.

  • 계층화 시스템

    시스템을 계층별로 분리한다.

  • 코드 온 디맨드

    프로그램을 클라이언트에 다운로드하여 실행한다.

  위 6가지 사항을 모두 지킬 필요는 없으나, 이러한 이상을 염두에 두고 실제로 동작하고 가치를 제공할 수 있는 시스템을 만드는 것이 중요하다.

REST의 2가지 측면

REST와 하이퍼미디어

애플리케이션의 상태는 하이퍼미디어의 링크를 따라가는 작업에 의해 변화한다. 이 때문에 하이퍼미디어는 애플리케이션 상태 엔진이라고 불린다.

하이퍼미디어를 이용한 애플리케이션은 리소스의 URI만 알면 어떤 애플리케이션이 제공하고 있는 리소스를 다른 애플리케이션에서도 재사용 할 수 있다는 장점이 있다.

리소스를 링크로 연결하여 하나의 애플리케이션을 구성한다는 개념은 REST의 근간을 이루는 사상이다. 이는 접속성이라고도 불린다.

REST와 분산 시스템

네트워크를 통한 함수 호출은 호출 횟수가 많아질수록 시스템 전체 성능의 저하를 가져온다.

반면 REST는 링크를 따라 애플리케이션의 상태를 변화시키기 때문에 전체적인 성능 저하를 억제할 수 있다. 또한 REST에 기초한 웹에서는 유니폼 인터페이스에 의해 인터페이스가 고정되어 있기 때문에 버전업을 하더라도 호환성 문제가 생기지 않는다는 장점이 있다.

REST의 의미

웹 전체의 아키텍처 스타일을 의미한다. 또한 우리들이 만드는 웹 서비스나 웹 API가 RESTful(REST의 제약에 따르면)이 되면 웹은 전체적으로 좋아지게 된다.