What Is Rest

REST 란 무엇인가 ?

REST 는 Roy Fielding 의 박사학위 논문 [1] 에서 네트워크 시스템의 구조적 형식 (architecture style) 을 설명하기 위해 만들어진 용어 입니다 .

[1]. http://www.ebuilt.com/fielding/pubs/dissertation/top.htm

왜 “ Representation State Transfer” 로 불리워지나 ? 사용자는 URL 을 사용하여 웹 리소스 (Web Resource) 를 참조합니다 . 리소스의 표현 (representation) 이 반환 됩니다 .( 이 경우 Boeing747.html 이라는 문서로 반 환 되어집니다 .) 이 표현 (Representation, 여기서는 Boeing747.html) 은 사용자 어플리케이션의 상태를 변경합니다 . 사용자가 Boeing747.html 의 하이퍼링크 (Hyperlink) 를 가로지른 결과 또 다른 리소스에 접근 하게 됩니다 . 새로운 표현 (Representation) 은 사용자 어리케이션을 전혀 새로운 상태에 변경 합니다 . 따 라서 사용자 어플리케이션이 각 리소스 표현의 상태를 변경합니다 .( 이동시킵니 다 ., transfer) -> Representation State Transfer

Representation State Transfer “ Representation State Transfer 는 ‘잘 디자인된 웹 어플리케이션은 어떻게 행동하는가 ?’ 에 대한 표상을 환기시킬 의도였다 . : 웹 페이지 (web page) 의 네트워크 ( 가상 상태 머신 , a virtual state-machine) 는 사용자의 링크 선택 ( 상태 변화 ) 에 의해 애플리케이션이 진행되고 , 다음페이지 결과 ( 어플리케이 션의 다음 상태의 표현 ) 는 사용자를 이동시키고 , 그들의 사용을 표현한다 .” - Roy Fielding

REST 의 동기부여

“ REST 개발 동기는 웹 작동 방식의 구조적 모델의 창조하기 위함이며 , 그

것은 웹 프로토콜 표준을 위한 가이드 프레임워크로서 이바지 할 수 있다 .

REST 는 바램하는 웹 구조 표현하기 위해 , 현존하는 문제를 도출을 돕기 위

해 , 대안이 되는 해결책 (alternative solutions) 대조하기 위해 이용되었으

며 , 프로토콜 확장이 성공적인 웹을 만드는 핵심 제한 사항과 충돌하지 않

음을 확신한다 . ”

- Roy Fielding

REST – 비표준

REST 는 비표준 입니다 . 여러분은 W3 에서 발표한 REST 명세를 볼 수 없습니다 . IBM 이나 MS, SUN 등에서 판매하는 REST 개발자 툴킷을 또한 볼 수 없습니다 . 왜 일까요 ? 왜냐하면 REST 는 그저 구조적인 형식 (architectural style) 입니다 . 여러분들은 그 형식을 숨길 수 없습니다 . 여러분들은 그것을 오직 이해 할 수만 있으며 , 그러한 형식으로 여러분의 웹 서비스를 디자인 할 수 있습니다 .

REST 는 표준은 아니지만 , 아래와 같은 표준을 사용합니다 .

HTPP

URL

XML/HTML/GIF/JPEG/etc ( 리소스 표현들 , Resource Reoresentations)

text/xml, text/html, image/gif, image/jpeg, etc ( 리소스 타입 , Resource Type, MIME Type)

REST 와 웹 (Web)

웹은 REST 시스템의 예 입니다 .

책 주문 서비스 , 검색 서비스 , 온라인 사전 서비스 등과 같이 오랫동안 사용해온 많은 것들이 모두 REST 기반의 웹 서비스 입니다 .

여러분들은 REST 를 사용하고 , REST 서비스를 만들어 왔으면서도 여러분들은 그것을 몰랐었습니다 .

예제 학습

이 예제는 이 구조적인 형식을 가장 잘 설명하는 예제입니다 .

여기서 한 회사에 REST 구조적 형식을 사용하여 배포 (deploy) 하는 3 개의 웹 서비스를 예로 들며 그러고 나서 이 서비스를 SOAP 을 이용하여 배포 되어진 예를 보여줄 것입니다 .

예를 보여준 후 REST 와 SOAP 에 대해 비교해 보겠습니다 .

Parts Depot 웹서비스 (Web Services)

Parts Depot, Inc 은 고객들이 사용 가능하도록 몇 가지 서비스를 배포 했습니다 .

- 부품의 목록을 가져오기 ( 서비스 )

- 특정 부품에 대한 상세한 정보를 가져오기 ( 서비스 )

- 구매 주문 전송하기 (PO) ( 서비스 )

REST 를 이용한 웹 서비스 구현

서비스 : 부품 목록 가져오기

- 웹 서비스는 부품 목록 리소스를 이용 할 수 있는 URL 을 만듭니다 . 예를 들면 , 사용자는 부품 리스트를 가져오기 위해 이 URL 을 사용 할 수 있습니다 .

a) http://www.parts-depot.com/parts

b) 웹 서비스가 만들어내는 부품 목록은 사용자에게 완전히 명백 ( 투명 , transparent) 합니다 . 이것은 결합도가 낮습니다 .(loose coupling)

- 웹 서비스는 이용자가 HTML 문서 (Document) 와 XML 문서의 부품 목록 중 원하는 조건을 지정 할 수 있도록 허용해야 한합니다 . 이것은 XML 문서를 원할때 어떻게 지정되는지를 보여줍니다 .:

a) http://www.parts-depot.com/parts?flavor=xml

돌아온 데이터 – 부품 목록 부품 목록은 각 부품에 대한 상세 정보를 얻을 수 있는 링크를 가지고 있 습니다 . 이것이 REST 의 주요 특징입니다 . 사용자는 한 상태에서 다른 상 태로 응답 문서 (Response Document) 속의 선택가능한 URL 들 사이에서 시험과 선택에 의해 이동합니다 .

서비스 : 특정 부품에 대한 상세 정보 가져오기

- 웹 서비스는 각 부품 리소스 접속 가능한 URL 을 만들어야 한다 . 예를 들면 , 여기에 사용자가 특정 부품에 어떻게 요청 (request) 하는지에 대해 나와있다 :

a) http://www.parts-depot.com/parts/00345?flavor=xml

돌아온 데이터 - 부품 계속해서 이 데이터는 , 이 부품의 명세표 (Specification) 을 하이퍼링크를 가로질러 찾을 수 있는 , 여전히 다른 상세정보와 연결되어 있습니다 . 각 응답 문서는 좀 더 상세한 정보를 얻기 위해 사용자가 이동하는 것을 허 용합니다 .

Question and Answers

Q : Parts Depot 에 수백만개의 부품이 있다면 , 거기에 수백만개의 static page 가 존재하게 되나요 ? 예를들면

http://www.parts-depot/parts/0000000

…

http://www.parts-depot/parts/9999999

A : 우리에겐 논리적 (logical) URL 과 물리적 (phygical) URL 의 구분이 필요합니다 . 예 의 URL 은 논리적 URL 입니다 . 이들은 원하는 리소스가 무엇인지 표현합니다 . 이것들 이 물리적인 객체를 나타내는 것은 아닙니다 . 논리적 URL 사용 이득은 리소스의 근본 적인 구현이 사용자에게 투명하게 바뀐다는 것입니다 .( 그것이 낮은 결합도 입니다 !) 당연히 Parts Depot 은 데이터 베이스에 부품 데이터를 저장 할 것입니다 . Parts Dep- ot 웹 사이트 코드는 각 논리적 URL 요청을 받아 , 어떤 부품이 요청되는지 결정하기 위해 그것을 분석하여 , DB 에 질의하고 , 사용자에게 되돌려줄 부품 응답 문서를 만듭 니다 . 위의 논리적 URL 은 다음과 같은 물리적 URL 과 대비 됩니다 .: http://www.parts-depot/parts/0000000.html … http://www.parts-depot/parts/9999999.html 이 URL 들은 물리적인 페이지 (HTML) 을 가리킵니다 . 만약 수백만개의 부품있다고 , 수 백만개의 정적인 페이지 (static page) 를 가지는 것은 매우 매력적이지 못한 것일 겁니 다 . 더욱이 이 표현되는 부품 데이터들이 구버젼의 표현 ( 올바르지 못한 정보 ) 을 사용 한다면 모든 사용자에게 충격적인 결과가 될 것입니다 .

Questions and Answers

Q : 내가 만약 복잡한 요청을 가지고 있다면 ? 예를들어 : “ 단가가 0.5$ 이내면서 수량이 10 개보다 적은 부품들만 보여주세요 .” 와 같은 요청를 한다면 간단한 URL 로서 어떻게 표현 하겠는가 ?

A : Parts Depot 에 대한 복잡한 질의는 사용자가 입력한 폼 (form) 을 이용하여 사용자가 검색 가능한 서비스를 제공 할 것입니다 . 사용자가 “ Go” 버튼을 누름으로써 사용자의 응답을 모아 응답에 기초하여 URL 을 생성합니다 . 항상 사용자가 직접 URL 을 입력하는 것은 아닙니다 .( 아마존 ( www.amazo n.com) 을 이용할 때를 생각해 보세요 . 우리는 아마존의 URL 을 입력하여 아마존에 접속하지만 , 그 후엔 폼 (form) 에 간단히 입력하여 URL 을 생성해 냅니다 .)

Questions and Answers

Q : REST 서비스에 대해 묘사 (described) 해주세요 .

A : 예를 들면 , REST 서비스는 WSDL 이나 WRDL(Web Resource Descript ion Language) 를 이용하는 것과 같다고 할 수 있습니다 . 이것에 대한 좀 더 자세한 설명은 조금 뒤에 설명하도록 하겠습니다 .

서비스 : 구매 주문 (Purchase Order, PO) 전송하기

- 웹서비스는 PO 를 전송하기 (submit) 을 위한 URL 을 만듭니다 . 사용자는 Parts Depot 이 디자인한 ( 그리고 WSDL 문서로 공표된 ) PO 스키마에 적합한 PO 인스턴스 문서 (instance document) 를 생성합니다 . PO 스키마에 적합한 PO 문서를 생성합니다 . 사용자는 HTTP POST 에 실어 PO.xml 을 전송합니다 .

PO 서비스 전송

PO 서비스는 PO 가 전송된 URL 의 HTTP POST 에 응답합니다 . 그러므로 사용자는 그 후 언제든지 PO 를 이용 할 수 있습니다 .

- PO 는 서버와 클라이언트 사이의 공유되어진 정보의 일부분이 됩니다 . 공유된 정보 (PO) 는 서버에 의해 주소 (URL) 로 주어지며 , 웹 서비스로서 외부에 노출됩니다 .

REST 기반 네트워크의 특징

Client-Server : pull 기반의 상호작용 방식 : 소비하는 컴포넌트가 표현을 가져온다 .( 호출하는 측이 데이터를 가져옵니다 .)

무상태 (Stateless) : client 에서 server 로의 각각의 요청 (request) 은 요청을 이해하기 위해 필요한 모든 정보를 반드시 포함해야 하며 , 서버에 어떤 저장된 context 의 이점을 취 할 수 없습니다 ..

Cache : 네트워크 효율을 개선하기위해 응답 (response) 은 캐쉬가능 / 불가능 여부 표시 (labeled) 가 반드시 가능해야 합니다 .

표준 인터페이스 (Uniform interface) : 모든 resource 는 일반적인 인터페이스 ( 예를 들면 , HTTP GET, POST, PUT, DELETE) 로 접근되어야 합니다 .

명명된 리소스 (Named resources) : 시스템은 URI 를 사용하여 명명된 (named) resource 로 구성되어야 합니다 .

상호연결된 리소스 표현 (Interconnected resource representations) : 리소스의 표현은 URL 에 의해 상호연결 되며 , 그로인해 사용자의 한 상태에서 다른상태로의 전이 ( 이동 ) 할 수 있습니다 .

SOAP Version

우리는 Parts Depot 의 REST 한 방식의 서비스의 구현에 대해 살펴보았습니다 .

이제 서비스의 SOAP 을 이용한 구현에 대해 알아 봅시다 .

Implementing the Web Services using SOAP

모든 트랜잭션은 같은 URL(URL1) 을 사용한다 . SOAP 서버는 메소드의 호출을 결정하기 위해 SOAP 메시지를 분석한다 . 모든 SOAP 메시지는 HTTP POST 를 사용하여 전송된다 .

Note about the SOAP URI

그러나 , 일반적인 SOAP 벤더를 사이에서는 여기서의 예를 따른다 . 예를 들면 , 여기에서 Apache SOAP 을 사용할때 모든 request 의 URL 은

[host]/soap/servlet/messagerouter

SOAP 에서 모든 메시지가 꼭 같은 URL 로 집중되어야 하는 것은 아니다 .

SOAP 을 이용한 웹서비스 구현

서비스 : 부품의 목록 가져오기

- 사용자는 원하는 절차를 지정한 SOAP 문서를 생성한다 .

그러고 나서 사용자는 HTTP POST 를 통해 이 문서를 SOAP 서버로 전송한 다 . : http://www.parts-depot.com/soap/servlet/messagerouter SOAP 서버는 어떤 메소드 (procedure) 를 호출할 것인지를 결정하기 위해 이 이 문서를 빠르게 분석한다 .

돌아온 데이터 – 부품 목록

링크의 없음 . 왜 그럴까요 ? 이 URL 은 웹 서비스의 포인터로 단지 SOAP

서비스의 URL 이 SOAP 서버를 가리킨다는 의미이외엔 없습니다 . 따라서

URL 은 이 URL 상에서 호출되는 메소드가 어느것인지에 대한 보충 설명이

필요합니다 .[ 물론 이 응답속에는 REST 한 (-ful) 서비스의 URL 이 포함되어 있습니다 .]

서비스 : 특정 부품에 대한 상세정보 가져오기

- 사용자는 해당 part-id 파라미터를 포함한 희망하는 절차를 서술한 SOAP 문서를 생성합니다 .

다시 , 사용자는 SOAP 서버로 이 문서를 HTTP POST 로 전달합니다 .: http://www.parts-depot/soap/servlet/messagerouter 이것은 이전에 부품 리스트를 요청했을 때 이용한 URL 과 동일한 URL 입 니다 . SOAP 서버는 메소드 호출을 결정하기 위해 이 문서를 분석합니다 .

돌아온 데이터 – 부품

다시 , 링크의 없음 . 응답 (response) 에는 “상세정보의 다음 단계”로 가기위

해 사용자가 이용 가능한 것이 없습니다 . 상세정보의 다음 단계로 가기 위

한 정보는 현재 이외의 곳 (out-of-band) 에서 찾아야 합니다 .

서비스 : 구매 주문 (Purchase Order, PO) 전송하기

- 사용자는 Parts Depot 이 생성한 PO 스키마를 준수하는 PO 인스턴스 문서를 포함한 SOAP 문서를 생성합니다 .

다시 , 사용자는 SOAP 서버로 이 문서를 HTTP POST 통해 전달합니다 .: http://www.parts-depot/soap/ servlet / messagerouter 이것은 이전에 다른 두개의 서비스를 요청했을 때 이용한 URL 과 동일 한 URL 입니다 . SOAP 서버는 메소드 호출을 결정하기 위해 이 문서를 분 석합니다 .

돌아온 데이터 – PO 승인

다시 , 링크 없음 .

REST 와 SOAP 비교

다음 슬라이드에서 REST 와 SOAP 에 대해 아래 항목들에 대해 비교해 보겠습니다 . :

- Proxy Server(Web intermediaries)

- 클라이언트 애플리케이션에서의 상태 변이 (Transitioning state)

- Caching(ie. Performance)

- 웹의 진화 (semantic Web)

- Generic interface(vs. custom interface)

- 상호운영성 (interoperability)

- Processing the payload

Letter Analogy

우리회사에는 메일센터 (receiving warehouse) 가 있다 . 모든 편지와 소포는 첫째로 그곳으로 가고 , 거기서 분산된다 .

SOAP 서버는 메일센터와 비슷하다 . – SOAP 서버는 모든 수신되는 SOAP 메시지를 받아 각각의 메시지를 프로세싱을 위한 애플리케이션에 충당하기위해 분산시킨다 .

그러나 한가지 큰 차이가 있다 .

- 메일센터에는 편지와 소포의 내부를 보는 것을 허락하지 않는다 . 편지와 소포가 어디로 갈지에 대한 모든 결정은 외부에 적힌 주소를 보고 처리한다 . 편지와 소포의 내부를 보려는 어떠한 시도든 연방법에 위배된다 .

- 반면 SOAP Server 는 SOAP 봉투 (envelope) 의 내부를 보는 것이 가능하다 . 사실 , 꼭 그래야 한다 . 왜냐하면 실제 목적 resource 외부에 표시되기는 커녕 봉투 안쪽에 감춰져 있기 때문이다 .

REST 의 모든 결정은 URL 과 HTTP 메소드에 달려있다 .

그래서 REST 와 SOAP 은 이점에 대해서는 기본적인 차이가 있다 . 우리는 다음 슬라이드에서 이것이 SOAP 으로 하여금 웹에서 상충되는 원인을 볼 수 있을 것이다 .

Proxy Servers

아래 시나리오를 고려해봅니다 .:

- 한 회사에서 3 개의 resource 를 배포 (deploy) 합니다 . – 각각은 Resource1, Resource2, Resource3 이라 하겠습니다 .

- 사용자는 Resource1 에 접근하길 바랍니다 .(Resource1 의 representation 을 받아오길 원합니다 .)

- 모든 사용자는 프록시 서버를 통해 요청합니다 .

- 프록시 서버는 Resource2 와 Resource3 에 접속하는 정책을 실시합니다 . 그러나 Resource1 은 접근을 제한합니다 .( 예를 들면 , Resource1 을 Hotmail 이라 가정하고 , 사용자의 회사 정책은 회사 회선을 이용한 Hotmail 의 접속을 금지합니다 .)

REST and Proxy Servers

URL 은 접속하길 바라는 resource 를 나타냅니다 .( 여기서는 Resource1 입니다 .)

HTTP 메소드는 원하는 동작을 나타냅니다 .( 예를들면 HTTP GET)

프록시 서버는 URL 상에 보여지는 resource 와 HTTP 메소드에 따라 작업 (operation) 을 허용할지 안할지의 여부를 결정합니다 .

SOAP and Proxy Servers

프록시 서버는 메시지가 목적지 resource 가 허용되는 것인지 여부를 결정할 수 없습니다 .( 그러한 정보는 봉투 (envelope) 속에 감춰져 있습니다 .)

여기서의 URL 은 원하는 resource 가 아닙니다 . SOAP 서버로 향하는 것인지도 확인 할 수 없습니다 .( 프록시 서버기준 ) 이것은 프록시 서버가 실제 목적하는 resource 가 무엇인지 결정하기 어렵게 합니다 . 아니 결정이 불가능합니다 .

프록시 서버는 요청되는 메시지가 무엇인지 알기 위해선 SOAP 메시지의 내부를 보는 것이 필요합니다 .

- 더욱이 , 프록시 서버는 메시지의 의미까지 이해할 수 있어야 합니다 .

이것이 사용자가 Resource1 에 접근하길 시도하기 위한 걸까요 ? 그것을 알려면 프록 시 서버가 모든 SOAP 애플리 케이션의 의미를 이해해야만 합니다 .

여기에 프록시 서버를 구현하는 2 가지 방법이 있습니다 .

1. 사용자가 접속하려는 각각의 SOAP 애플리케이션의 의미를 이해시키기 위한 프록시 서버 프로그램 . 이것은 불가능한 방법입니다 . – 각각의 새로은 SOAP 애플리케이션을 위해 프록시 서버가 업데이트 되어야 합니다 .

2. 모든 SOAP 메시지가 RDF/DAML 로 쓰여진다 하더라도 프록시 서버가 동적으로 요청되는 resource 와 메소드를 구별해 낼 수 있어야 합니다 .

어떤 resource 에 이 SOAP 메 시지가 접근을 시도하는 걸까 요 ? 어떤 resource 를 작동시 키려고 시도하는 걸까요 ?

Web Intermediaries

프록시 서버는 웹 중간단계의 하나의 예 입니다 . 다른 예들로는 gateway 들이나 , 캐시들 그리고 기타 등등의 것들이 있습니다 . 전형적인 웹 요청은 여러 중간단계 ( 매개체 , intermediaries) 를 거치게 됩니다 .

웹 중간단계에서는 사용자의 요청이 목적하는 resource 와 요청되는 메소드가 분명하게 보여지는 것이 이해가능한때 이유있는 결정을 해야하는 훨씬 더 많은 기회를 가지게 됩니다 .

우리가 본것과 같이 SOAP 의 봉투 (envelope) 안에 포함된 목적 resource 와 요청 메소드는 중간단계들이 그들의 일을 수행하기 매우 어렵게 만듭니다 .

State Transtions

상태 머신 (state machine) 과 같은 사용자 애플리케이션 생각해 봅시다 . 각각의 자원들 (resource representation) 은 다음 상태로의 전이를 위한 표시 ( 원인 , cause) 을 받게 됩니다 .

사용자 애플리케이션의 상태 전이 다이어그램

State Transitions in a REST based Network

각각의 페이지 (resource representation)

은 하이퍼링크를 가지고 있습니다 . 하이퍼

링크를 따라 사용자는 다음 상태로 이동합

니다 . 따라서 , 각 페이지 그 자신이 다음상

태를 가르키는 포인터 입니다 .

Parts Depot 의 예제를 다시 생각해 봅시다 . 부품 리스트 resource 는 아래와 같은 내용을 리턴합니다 .

이 문서에는 각 부품에 대한 상세정보가 제공되는 resource 로의 하이퍼링 크가 포함되어 있습니다 . 사용자 애플리케이션에서 하이퍼링크중 하나를 선택하면 하이퍼링크가 나타내는 resource 의 페이지 (representation) 를 받 을 수 있습니다 . 이것이 다음 상태로의 사용자 애플리케이션의 이동입니다 .

Q : 만일 내가 브라우져 앞에 앉아있다면 , 그 결정이 어떤 하이퍼링크를 선택하느냐에 따라 이루어지는지에 대한 이해가 가능하다 . 하지만 이 모든것이 사람의 매개없이 프로그래밍에 의해 자동적으로 이루어 진다면 , 어떻게 어떤 하이퍼링크를 선택하는지에 대한 결정이 이루어 지는가 ?

A : XML 하이퍼링크 기술은 Xlink 이다 . 목적하는 resource 의 URL 을 제공하기 위해 추가된 이 기술로 xlink:role 을 사용하여 연결되는 resource 에 대한 데이터를 제공할 수 있다 . 만일 사용자 애플리케이션이 xlink:role 의 의미를 이해하는 것이 가능하다면 다음을 결정할 resource 가 어느것인지 결정하는 것을 가능하게 할 수 있다 . 이것은 매우 재미있는 것이다 . 애플리케이션이 동적으로 어떤 resource 로 접근할 것인지에 대해 결정한다 .( 스스로 선택하는 오토마타가 된다 .) 만약 사용자 애플리케이션이 xlink:role 속성에 대해 평가 할 수 없다면 , 결정하는데는 외부적인 요소가 필요 할것이다 .( 이 말은 그 결정은 이미 애플리케이션이 만들어지던때에 결정되어져야 한다는 말이다 .)

State Transitions in a SOAP based Network

SOAP 시스템의 각 SOAP 메시지는 하이

퍼링크가 없는 단순한 데이터입니다 . 필

연적으로 , 어떤 resource 가 다음 상태로

의 접근을 결정하는 것은 외부적 요소입

이다 .

State Transitions in a SOAP based Network

Parts Depot 의 예제를 다시 생각해 봅시다 . 부품 리스트 resource 는 아래와 같은 내용을 리턴합니다 .

SOAP 문서에는 하이퍼링크가 없습니다 . 이 문서는 섬과 같이 웹 세상에서 웹의 REST 로부터 단절되어 있습니다 . 다음에 무엇을 해 야하는지에 대한 정보는 외부 어딘가에서 찾아야 합니다 .

Why don’t SOAP Documents Contain Hyperlinks?

순수한 SOAP 시스템 , 어딘가에서 접속되어지는 모든 SOAP 기반의 웹서비스 , 에서는 각 SOAP 문서는 섬과 같습니다 .

이 이유는 간단합니다 . : SOAP 에서의 URL 은 그 자체로서는 의미가 없습니다 . URL 은 단지 SOAP 서버를 가르키는 것입니다 . URL 이 의미가 있어지기 위해서는 SOAP 메시지가 수반되어야 합니다 .

SOAP Working Group 은 현재 SOAP HTTP GET 을 이용하는 방식에 대해 연구중입니다 .

Caching(i.e., performance)

네트워크 기반의 애플리케이션에서의 대화는 종종 병목현상을 겪게 됩니다 .

REST and Caching

Cache 는 사용자 가져와야할 데이터와의 거리를 짧게 하므로서 요청 시간을 줄일 수 있습니다 .

REST and Caching

Resource 요청의 결과에는 이 결과가 cache 가능하거나 데이터가 오래된 (stale) HTTP header 인지 가리키는 것을 포함합니다 .

만약 HTTP header 가 cacheable 하다고 말한다면 cache 서버는 local 에 copy 를 해놓습니다 .

후에 , 같은 resource 에 대한 사용자 요청이 들어오면 local 에 cache 된 copy 본은 리턴합니다 .

SOAP and Caching

여러분이 SOAP 메시지를 전송할때는 항상 HTTP POST 를 통해 전송합니다 . 심지어 메시지의 목적이 단순한 데이터를 “얻기 (GET)” 위함이라 하더라도 말이죠 .

- 캐시 서버는 사용자가 요청하는게 무엇인지 HTTP 메소드로는 알 수 없습니다 .

SOAP 의 URI 는 항상 SOAP 서버를 향하지만 실제 목적은 아닙니다 .

- 필연적으로 , 캐쉬 서버는 어떤 resource 를 요청하는지 URI 로 부터 알아낼 수 없습니다 .

따라서 , SOAP 메시지를 받은 캐시 서버는 어떤 데이터를 요청하는 것인지 , 어떤 ( 메소드의 호출같은 ) 자원을 요청하는지 결정할 수 없습니다 .

- 결론적으로 SOAP 통한 캐싱은 불가능 합니다 .

“ 나는 목적하는 resource 가 무엇인지 알 수 없습니다 . 심지어 resource 가 요청되 는지도 알 수 없습니다 . 그 래서 나는 요청을 forward 할 뿐입니다 . 캐싱하지 않 습니다 .”

Evolving the Web (Semantic Web)

팀 비너스리의 비젼은 Web 이 의미있는 Web(semantic Web) 이 되도록 하는 것입니다 . (1)

그의 비젼이 가진 핵심 컴포넌트 (key components) 중 하나는 모든 resource 가 웹상에 그 자신의 URL 을 소유하는 것입니다 .

- Axiom 0 : Universality1

a) 어디에 위치한 resource 든 URI 가 주어질 수 있습니다 .

- Axiom 0a : Universality 2

a) 어떤 의미를 가진 resource 든 URI 가 주어질 수 있습니다 .

REST 스타일은 이 비젼과 원칙이 일치합니다 . – 모든 resource 는 논리적 URL 을 가지고 있습니다 .

SOAP URI 의 스타일은 모든 resource 가 하나의 URI 를 통해 SOAP 서버로 전송되므로 semantic Web 의 비젼과 일치 하지 않습니다 .

(1) http://www.w3.org/DesignIssues/Axioms.html

Generic Interface

REST( 와 Web) 의 주요특징은 모든 resource 는 generic interface 를 가지고 있다는 것입니다 . 즉 , resource 에 대한 모든 접근은 HTTP GET, POST, PUT, DELETE 을 통해 이루어 집니다 .

우리는 URI 조합과 일반적인 메소드 셋 (set, URI, method) 으로 어떻게 Web 컴포넌트들이 유용하게 작업을 수행하는 지를 보았습니다 .

- Proxy Server(URI, method) -> accept/reject

- cache(URI, method) -> forward request/return cached representation

SOAP 에는 메소드 셋 (set) 의 정의가 없습니다 . 각각의 SOAP 애플리케이션은 그 자신의 메소드 셋을 자유롭게 정의 합니다 .

- 그 결과 , 툴은 매 애플리케이션 (per-application) 마다 커스터마이징 되어야 합니다 . 이것은 확장성이 떨어집니다 . Web 에서 , 독립성과 확장성은 매우 중요한 것으로 이것은 그다지 좋은 생각이 아닙니다 .

Interoperability

정보처리 상호작용의 핵심은 표준화에 있습니다 . 그 이유는 오늘날의 웹은 표준화 되어가고 있기 때문에 Web 상의 독립적 resource 상호작용 가능해야 합니다 ..

- Addressing and naming resource -> URI

- Generic resource interface -> HTTP GET, POST, PUT, DELETE

- Resource representation -> HTML, XML, FIG, JPEG, etc

- Media type -> MIME type(text/html, text/xml, etc)

이것들이 REST 가 주창하는 표준들입니다 .

SOAP 은 훨씬 커스터마이징적인 것에 의존합니다 ..

- Addressing and naming resource -> 각 SOAP 메시지는 그 자신에 명명된 resource 의 고유한 method 를 제공합니다 ..

- Resource interface -> 각 SOAP 애플리케이션 그 자신의 interface 를 정의합니다 ..

Processing the Request/Response Payload

다음의 REST 와 SOAP 둘은 여러분에게 데이터의 의미에 대한 사전 동의가 필요하다 .

다음의 REST 와 SOAP 은 사용자 애플리케이 션에 이들 응답에 대한 이해를 필요로 한다 .

Processing the Request/Response Payload

만일 전송된 데이터 (payload) 가 RDF 나 DAML 포멧이라면 사용자 애플리케이션이 응답하는 데이터의 의미를 동적으로 배우는 것이 가능 할 것입니다 .

이전에 보았듯이 , REST 는 각 응답마다 다음 상태로의 연결을 생성합니다 . 우리는 사용자 애플리케이션이 어떤 링크를 연결 할 것인지에 대한 동적인 판단이 가능하다는 것을 앞서 암시했었습니다 . 따라서 , 응답 데이터의 동적인 학습은 링크 선택의 동적인 판단과 합쳐져 스스로 판단하는 오토마타 (self reasoning automata) 를 만들어 냅니다 . 이것이 Web 의 다음단계 입니다 .

Recommandation

Web 의 context 에서 REST 의 접근법으로 선호되며 , 가장 비용적으로 효과적인 서비스 구현을 위한 설계 스타일은 확장성 있어야 하고 , 우선순위 계획 없이 동적인 연결이 가능해야 하며 , 사용자와 서비스사이의 의존성이 없어야 하며 , 캐싱과 보안이 가능해야 합니다 ..

Web 환경에서의 SOAP 사용은 몇 가지 주요한 있습니다 .

- 목적하는 resource 를 URL 로 부터 간단하게 알 수 없다 . 그 내용은 SOAP 메시지 안에 숨겨져 있습니다 .

- 호출되는 메소드를 HTTP method 로 부터 알 수가 없다 . 이 또한 SOAP 메시지 안에 숨겨져 있습니다 .

- 메소드 셋 (set) 이 임의적이다 . 모든 SOAP 애플리케이션은 그 자신의 메소드 셋을 자유로이 정의할 수 있습니다 .

SOAP 메시지는 프록시 서버나 캐시서버에서 활용될 수 없음을 논의 하였습니다 . URL 이 없는 SOAP 메시지는 Web 과는 이질적이며 그 자신을 Web 에서 고립시키게 됩니다 . 결국 , Web 이 나아가야 할 바는 모든 resource 에 그 자신을 나타내는 URI 를 갖는 것인데 SOAP 의 한 URI 속에 모든 resource 를 응집시키는 속성은 Web 의 비젼에 반하게 됩니다 .

그럼 SOAP 의 역할은 무얼까요 ? SOAP 의 가장 좋은 활용법은 닫힌 시스템 (closed system, 모든 관계자들이 알고있는 시스템 ) 에서 사용 되는 것입니다 . 닫힌 시스템의 각각의 관계자는 다른 관계자의 API 를 이해하여 커스터 마이징 가능하며 , 최고의 효과를 보기위한 옵티마이징을 할 수 있습니다 .

REST Best Practices

여러분이 외부에 노출시키기를 원하는 각 resource 를 위한 URI 를 제공한다 . 이것은 팀 비너스리의 Web 의 원리와 W3 TAG 권고안과 일치합니다 .

물리적 (physical) URI 보다 논리적 (logical) URI 를 선호합니다 . 예를들면 :

- 논리적 : http://www.boeing.com/airplane/747

- 물리적 : http://www.boeing.com/airplane/747.html

논리적 URI 사용자 어플리케이션의 영향을 주지않는 리소스의 구현의 변경을 허용합니다 .

그결과 논리적 URI 는 동사가 아닌 명사로 사용됩니다 . 리소는 “액션 (action)” 이 아닌 “어떤것 (things)” 입니다 .

모든 HTTP GET 의 부작용이 없도록 만들어야 합니다 . 요청 (request) 에 안전 (safe) 하도록 만들라는 것입니다 .

응답 (response) 속의 링크 (link) 를 요청 (request) 으로 사용하세요 . 응답을 다른 데이터와 연결하는 것입니다 . 그것은 사용자 어플리케이션이 “스스로 - 작동 (self-profelled)” 가능하게 합니다 . 그것은 응답 (response) 그 자신속에 포함된 “취해야할 다음단계는 무엇인가”에 대한 정보입니다 . 이 응답은 저 링크가 포함되지 않은것과는 대조적입니다 . 따라서 “취해야할 다음단계는 무엇입니까 ?” 의 결정을 외부에서 선택하게 됩니다 .

REST Best Practices