REST는 아키텍처 스타일이므로 실제로 시스템(웹 서비스와 그 이외도 포함)을 설계할 때는 그 시스템의 아키텍처를 만들어야만 한다.
REST에 기초한 아키텍처를 구축할 경우라도 REST를 구성하는 스타일 중 몇 가지를 제외하더라도 상관없다.
예를 들어, 쿠키 정보 등을 통해 세션에 값을 저장하도록 하여 스테이트풀 하지만,
URI 형식 등은 REST의 제약에 따르는 아키텍처도 생각해 볼 수 있다.
말 그대로 설계 작업이기에 소프트웨어와 시스템의 설계에서는 아키텍처 스타일의 이상과 타협해야만 하는 부분도 나온다.
보다 적합한 다른 아이텍처 스타일이 있기 때문에 무엇보다도 대부분의 REST 스타일을 제외해야만 하는 경우에 무리하게 REST를 채용할 필요가 없다.
예를 들어 서버를 거치지 않고 피어(Pear)사이에서의 통신이 필요한 경우는 REST보다 P2P가 좋다.
REST의 2가지 측면
REST와 하이퍼미디어
보통 웹을 사용할 때는 링크를 따라가며 다양한 리소스에 접근하게 된다.
이 작업들의 최소 단위는 '웹상의 리소스들이 가지는 링크를 따라가는' 것이다.
웹이 가진 이 특징을 REST에서는 애플리케이션 상태 엔진으로서의 하이퍼미디어(Hypermedia as the engine of application state)라고 한다.
애플리케이션 상태는 하이퍼 미디어의 링크를 따라가는 작업에 의해 변화한다.
이것이 하이퍼미디어가 애플리케이션 상태 엔진이라고 불리는 이유이다.
하이퍼 미디어를 이용한 애플리케이션은 리소스의 URI만 알면 어떤 애플리케이션이 제공하고 있는 리소스를 다른 애플리케이션에서도 간단히 재사용할 수 있다는 장점이 있다.
리소스를 링크로 연결하여 하나의 애플리케이션을 구성한다는 개념은 REST의 근간을 이루는 사상이다. (= 접속성 Connectedness)
REST와 분산 시스템
RPC와 CORBA, DCOM 등의 분산 오브젝트에서는 함수나 메서드 단위로 서버 쪽의 처리를 호출한다.
네트워크를 통한 함수 호출은 동일 프로세스 내의 함수 호출과는 비교되지 않을 만큼 오버헤드가 심하기 때문에 호출 횟수가 많아질수록 시스템 전체 성능의 저하를 가져온다.
오버헤드로 인한 성능 저하 문제는 이론적으로는 인터페이스의 입도를 크게 하고 호출 횟수를 줄임으로써 회피할 수 있지만 실제로는 구현하기 어렵다.
RPC와 분산 오브젝트는 서버마다 다른 인터페이스를 가지며, 개별 인터페이스는 프로그램 라이브러리의 인터페이스를 기반으로 개발하는 경우가 많기 때문이다.
일반적으로 라이브러리에 좋다는 인터페이스(API)는 네트워크로 호출하기에는 지나치게 작은 입도이다.
그에 비해 REST에 기초한 웹 서비스는 링크를 이용해 애플리케이션을 실현한다.
리소스는 그 자체로 의미를 가진 하나의 데이터이며, RPC 함수에 의해 주고받는 데이터보다 입도가 크다.
그러므로 링크를 따라 애플리케이션의 상태를 변화시키는 편이 전체적인 성능 저하를 억제할 수 있다.
또한, RPC와 분산 시스템에서는 기능을 추가해 버전 업 할 때마다 메서드가 늘어나거나 메서드의 인수와 반환값이 바뀌어 API호환성이 상실된다.
이 때문에, 기존의 클라이언트르 모두 동시에 변경해야한다. 이는 웹과 같은 대규모 시스템에서는 비현실적이다.
그에 반해, REST에 기초한 웹에서는 유니폼 인터페이스에 의해 인터페이스가 고정되어 있어 호환성 문제는 발생하지 않는다.
HTTP를 구현한 클라이언트라면 동일하게 접속할 수 있다.
REST의 의미
REST는 웹 전체의 아키텍처 스타일이다.
우리들이 만드는 웹 서비스나 웹 API는 웹을 구성하는 일부분이다.
RPC(remote procedure call)
원격 프로시저 호출(remote procedure call, 리모트 프로시저 콜, RPC)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다.
다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.
- 출처: 위키피디아
CORBA(Common Object Request Broker Architecture)
CORBA는 네트웍에서 분산 프로그램 객체를 생성, 배포, 관리하기 위한 규격으로 네트웍 상의 서로 다른 장소에 있는 프로그램들이 “인터페이스 브로커”를 통해 통신이 가능하도록 해준다.
OMG(Object Managemet Group)에서 개발.
- 출처: blog.naver.com/bluejames77/80001173027
DCOM(Distributed Component Object Model)
DCOM은 네트웍 상에서 클라이언트 프로그램 객체가 다른 컴퓨터에 있는 서버 프로그램 객체에 서비스를 요청할 수 있도록 해주는 마이크로소프트의 프로그램 인터페이스 표준이다.
COM은 같은 컴퓨터(윈도우95나 NT 시스템) 내에서 사용될 수 있도록 클라이언트와 서버에 인터페이스 집합을 제공해 준다.
'기술 노트 > 웹' 카테고리의 다른 글
[웹을 지탱하는 기술] URI의 스펙 (0) | 2021.04.28 |
---|---|
[웹을 지탱하는 기술] REST 웹의 아키텍처 스타일 - 02 (0) | 2021.04.17 |
[웹을 지탱하는 기술] REST 웹의 아키텍처 스타일 - 01 (0) | 2021.04.17 |
[웹을 지탱하는 기술] 웹이란 무엇인가? (0) | 2021.04.17 |