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) 프로세싱

현재의 문제점

어려운 사용법, 무거운 프로토콜

표준의 부재, 관리가 어려움

댓글