REST
태그 :
- 개념
- REST(Representation State Transfer)의 정의 - WWW(World Wide Web)처럼 자원을 정의하고 접근하는 메커니즘을 기반으로 한 네트워크가 가능한 시스템을 만드는 아키텍처 원칙과 소프트웨어 아키텍처 스타일의 집합 - Roy Fielding의 논문(Architectural Styles and the Design of Network-based Software Architectures)에서 정의되어 사용
I. 형상관리 활동을 점검하는 형상감사의 개요
가. REST(Representation State Transfer)의 정의
- WWW(World Wide Web)처럼 자원을 정의하고 접근하는 메커니즘을 기반으로 한 네트워크가 가능한 시스템을 만드는 아키텍처 원칙과 소프트웨어 아키텍처 스타일의 집합
- Roy Fielding의 논문(Architectural Styles and the Design of Network-based Software Architectures)에서 정의되어 사용
나. REST의 특징
- 부수적인 시맨틱 레이어나 세션 관리를 추가하지 않고도 HTTP 같은 프로토콜로 데이터를 전달하는 프레임워크를 설명
- 부수적인 시맨틱 레이어나 세션 관리를 추가하지 않고도 HTTP 같은 프로토콜로 데이터를 전달하는 프레임워크를 설명하는 데 사용
- URI(Uniform Resource Identifiers)를 사용하여 주어진 자원 표현의 위치를 알아내고 접근
- 표현 상태(representational state)라 알려진 자원 표현은 만들어질 수도, 찾아올 수도, 수정될 수도, 삭제될 수도 있음
- HTTP처럼 웹과 관련된 기존 기술, 표준, 프로토콜을 활용할 수 있음
- 무상태 대화(stateless conversation) 내에서 동작하기 때문에 RSS, RDF, OWL, Atom 같은 등록 기반의 기술이 쉽게 보급될 수 있게 영향
II. REST의 구성개체 및 개체간 상호작용
가. REST의 구성체계(기본 개체)
구성체계 |
상세설명 |
데이터 요소 |
- 데이터, 식별자(URI와 URL), HTML 문서, 이미지와 같은 데이터 표현 |
컴포넌트 |
- 아파치(Apache) http와 마이크로소프트Ⓡ IIS(Internet Information Service) 같은 고유 서버, 스퀴드(Squid)와 CGI 같은 게이트웨이(gateways), 컨틀렛(Gauntlet)과 넷스케이프(Netscape) 프록시 같은 프록시, 웹 브라우저나 모바일 기기 같은 사용자 에이전트 |
커넥트 |
- Libwww 같은 클라이언트 커넥터, NSPAPI 같은 서버 커넥터, 브라우저 캐시 같은 캐시 등 |
나. REST의 개체간의 상호작용
- 커넥터는 컴포넌트간에 통신할 수 있게 프로토콜 포트로 구체화
- 컴포넌트는 여러 개의 클라이언트 또는 서버 커넥터를 사지고 다른 컴포넌트와 통신을 처리
다. HTTP 기반의 REST의 예제
- GET, PUT, POST, DELETE라는 표준 HTTP 메서드를 사용하여 자원의 표현 상태에 접근
- GET : 발행자가 소비자에게 자원의 현재 표현 상태를 전달할 때 이 메서드를 사용
- PUT : 소비자가 발행자에게 자원의 수정된 표현 상태를 전달할 때 이 메서드를 사용
- POST : 소비자가 발행자에게 자원의 새 표현 상태를 전달할 때 이 메서드를 사용
- DELETE : 자원의 표현 상태를 삭제 상태로 변경해야 하는 정보를 전달할 때 이 메서드를 사용
III. REST와 SOAP과의 비교 및 활용분야
가. REST와 SOAP와의 비교
구분 |
SOAP |
REST |
장점 |
- 언어, 플랫폼, 전송(Transport) 중립 - 분산컴퓨팅 환경에서 사용하기 위한 디자인 - 웹서비스를 위해 널리 사용되는 표준이며, 다른 표준과 통합을 통한 확장성이 뛰어나고 다양한 Vendor를 통한 지원이 이루어지고 있음 - 에러처리 기능이 포함되어 있음 |
- 언어, 플랫폼 중립 - 일반적으로 SOAP보다 웹서비스 개발이 더 쉬움 - 매시업을 통한 새로운 형태의 웹서비스 개발을 쉽게 할 수 있음 - Virtual Earth API와 연계하여 교통정보 제공 웹 사이트를 개발하는 등 |
단점 |
- 개념적으로 REST보다 더 어렵고, 무거움 - 개발이 REST 보다 어렵고 Tool이 필요한 경우가 많음 |
- 분산환경에서 메시지가 중간 경유지를 여러 번 통과하는 경우 사용 하기 어려움 - 보안, 정책, 안정적인 메시지 전달을 지원하기 위한 표준이 부족함 - 복잡한 요구사항을 표현하기 위해 직접 구현해야 함 |
IV. REST의 서비스 개념도, 요청 Method, 비교
가. REST 개념도
- URI를 이용하여 Resource에 접근하고 HTTP기본 Method를 사용하여 처리
나. HTTP기반 REST 요청 Method
구분 |
요청 Method |
CRUD Oper |
POST |
Create a new resource |
CREATE |
GET |
Retrieve a representation of a resource |
READ |
PUT |
Modify or overwrite an existing resource |
UPDATE |
DELETE |
Delete an exiting resource |
DELETE |
다.
|
SOAP 기반 웹서비스 |
RESTful 웹서비스 |
|
배경 및 현황 |
- 기업을 위한 비즈니스 응용에서부터 출발 - IBM, BEA(현재 IBM으로 통합), Oracle 등을 선두로 하는 웹서버 벤더에서 주창 - SOA의 서비스는 대부분이 비즈니스 컴포넌트로서의 의미를 가짐 |
- QEB 2.0은 서비스 애플리케이션에서부터 시작 - 구글, 아마존, 야후와 같은 인터넷 서비스 기업에 의해서 주창 - 앱이나 뉴스, 가젯 등과 같이 UI 성격을 갖는 서비스가 대다수임 |
|
특징 |
- The Machine-Readable Web : 사람보다는 기계가 해석할 수 있는 웹 - Stateful : 오퍼레이션 중 서비스 상태가 일관되게 유지, 관리되어야 함 - 엄격한 문법 검사, 서비스 계약에 충실 - 웹 서버 등 웹서비스 개발 환경이 지원되어야 함 |
- The Human-Readable Web : 사람이 해석할 수 있는 웹 - Stateless : 오퍼레이션 중 서비스/리소스의 상태를 관리하지 않음(HTTP의 기본 메커니즘), 필요한 경우에 직접 관리해야 함 - 기본 XML만으로 서비스 개방 가능 - 별도의 개발 환경 지원이 필요 없음 |
|
적 용 기 술 |
전달 매커니즘 |
Remote Procedure Call |
Publish/Syndicate Pattern |
전달 프로토콜 |
SOAP/HTTP,SMTP |
HTTP |
|
서비스 명세 |
WSDL |
WADL, SML, JSON, Hrest(시맨틱 REST) 등 |
|
서비스 레지스트리 |
UDDI |
없음 |
|
필요 스벅 |
W3C의 WS-*스택(WS-addressing, WS-security 등) |
없음 |
|
주요 적용 분야 |
트랜잭션 프로세싱 |
데이터와 UI(User Interface) 프로세싱 |
|
현재의 문제점 |
어려운 사용법, 무거운 프로토콜 |
표준의 부재, 관리가 어려움 |