대용량 분산 아키텍쳐 설계 #5. rest

대용량 분산 아키텍쳐#5.REST

조대협http://bcho.tistory.com

http://bcho.tistory.com/

ICE Break

Roy Fielding REST

Open API

Service Companies

WebService

목차

1. Beginning of REST2. Basic of REST3. Basic REST example4. Advanced REST example5. Advanced REST6. REST Implementation7. Reference Architecture of REST8. REST Stub generator9. REST implementation considerations

1. Beginning of REST

• 웹 (HTTP) 의 공동 창시자 Roy Fielding 의 2000 년 박사 논문에 소개 됨 .

• 기존의 웹이 HTTP 의 장점을 100% 활용하지 못하고 있음• 네트워크 아키텍쳐 (Not a protocol)• De facto Standard• 오픈 진영 (Google ,Amazon) 에 의해서 주도됨

2. Basic of REST

• REST 의 구성구성 요소 내용 표현 방법

Noun 자원을 정의 HTTP URI

Verb 자원에 대한 행위를 정의 HTTP Method

Representa-tions

자원에 대한 행위의 내용을 정의 HTTP Message Pay Load

2. Basic of REST

• Examples 자바스터디 시스템에 이름이 “ bcho” 이 사용자를 생성

자바스터디 시스템에서 이름이 “ bcho” 이 사용자 정보를 조회

자바스터디 시스템에서 이름이 “ bcho” 인 사용자 정보를 변경

자바스터디 시스템에서 이름이 “ bcho” 인 사용자 정보를 삭제

URI : http://www.javastudy.co.kr/users/bchoMethod : GET

URI : http://www.javastudy.co.kr/users/bchoMethod : POST <user> <name> 조대협 </name> <email>[email protected]</email> </user>

URI : http://www.javastudy.co.kr/users/bchoMethod : PUT <user> <name> 조대협 </name> <email>[email protected]</email> </user>

URI : http://www.javastudy.co.kr/users/bchoMethod : DELETE

Noun

Verb

Representation

2. Basic of REST

• Noun Noun 은 Resource 를 정의하며 각각 Unique 한 URI 를 갖는다 .

Select(GET) 에 한하여 Query String 을 이용하여 URI 를 정의할 수 있다 .

Resource 의 URI 는 Human Readable 한 포맷을 사용한다 .

Unique 한 URI 사용으로 인해서 GET 에 대해서 웹캐쉬 사용가능 비약적인 성능 향상

http://example.org/products?category=food

http://example.org/products/1234http://example.org/user/scotthttp://example.org/account/XA123-345

권장 http://example.org/orders/2007/11권장하지 않는 사용법 http://example.org/ITGKA/XATTY

2. Basic of REST

• Verb HTTP Method 를 이용하여 Resource 에 대한 행위 (CRUD) 를 나타냄

오래된 네트워크 장비나 서버의 경우 GET/POST 만 허용 HTTP 헤더 사용 x-http-method

POST,GET,PUT,DELETE 만으로 표현하기 어려운 행위가 있음 행위를 재 정의 : 이메일을 보낸다 이메일을 생성한다 . 제어의 의미나 기타 행위에 대해서는 내부적인 표준 마련 PUT : CONTROL

Http Method Description

POST Create

GET Select

PUT Create or Update

DELETE Delete

OPTION Get available Method

2. Basic of REST

• Representation– GET 으로 오는 리소스의 데이타를 표현– UPDATE 나 CREATE 시에 전송되는 리소스의 데이타를 표현– 포맷

• XML 또는 JSON 을 주로 사용 ( 표준은 없음 )• 하나의 리소스에 대해서 여러가지 포맷을 동시 사용이 가능• HTTP Content-Type /Accept 헤더로 정의 가능

– 구조• 데이타의 컬럼 구조 (Scheme) 를 정의• REST 에서는 구조를 정의하는 명시적인 방법이 없음 (CF. WebService/WSDL)

3. Basic REST example

• REST 를 이용하여 계좌이체를 수행하는 애플케이션 • 시나리오

STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다 . STEP 2. 사용자 ID 로 해당 사용자가 가지고 있는 계좌 목록을 조회한다 . STEP 3. AZA12093 계좌에서 ADK31242 계좌로 $100 를 계좌 이체한다 . STEP 4. 이체된 결과를 확인한다 .


• STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다 . 로그인 했다고 가정

• STEP 2. 사용자 ID 로 해당 사용자가 가지고 있는 계좌 목록을 조회한다REQUEST

URI http://bank.org/accounts?findby=7t676323a

METHOD GET

RESPONSE

HTTP Code 200 OK

Pay Load Content-Type: application/xml;charset=UTF-8 <accounts xmlns="urn:org:bank:accounts"> <account> <id>AZA12093</id> <customer-id>7t676323a</customer-id> <balance currency="USD">993.95</balance> </account> <account> <id>ADK31242</id> <customer-id>7t676323a</customer-id> <balance currency="USD">534.62</balance> </account></accounts>

사용자 ID

두개의 계좌 정보가 리턴됨


• STEP 3. AZA12093 계좌에서 ADK31242 계좌로 $100 를 계좌 이체한다 .REQUEST

URI http://bank.org/transfer

Method POST

PayLoad Content-Type: application/xml;charset=UTF-8<transfer xmlns="urn:org:bank:accounts"> <from>account:AZA12093</from> <to>account:ADK31242</to> <amount currency="USD">100</amount> <note>RESTing</note></transfer>

RESPONSE

HTTP Code 201 Created

Pay Load Content-Type: application/xml;charset=UTF-8<transfer xmlns="urn:org:bank:accounts"> <from>account:AZA12093</from> <to>account:ADK31242</to> <id>transfer:XTA8763</id> <amount currency="USD">100</amount> <note>RESTing</note></transfer>

계좌 이체 Transaction Id

계좌 이체 Transaction 이 생성됨


• STEP 4. 하루가 지난후 계좌이체 결과를 조회

REQUEST

URI http://bank.org/check/XTA8763

Method GET

RESPONSE

HTTP Code 200 OK

Pay Load Content-Type: application/xml;charset=UTF-8<status xmlns="urn:org:bank:accounts"> <code>01</code> <message xml:lang="en">Pending</message></status>

계좌 이체 진행중

4. Advanced REST example

• 앞의 예제에서 누락된 HTTP 의 특성– LINK 의 누락

• Link 는 리소스간의 관계를 정의할 수 있다 .• Link 를 통해서 리소스간의 BPM 과 같은 Work-flow 를 정의할 수 있다 .

– Content-Type 의 누락• Input/Output Message Type 을 정의할 수 있다 .

이것이 과연 REST?가장 기초중의 기초 , 그럼 진짜 REST 는 ?


• STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다 . 로그인 했다고 가정

• STEP 2. 사용자 ID 로 해당 사용자가 가지고 있는 계좌 목록을 조회한다REQUEST

URI http://bank.org/accounts?findby=7t676323a

METHOD GET

RESPONSE

HTTP Code 200 OK

Pay Load Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8<accounts xmlns="urn:org:bank:accounts"> <account> <id>AZA12093</id> <link href="http://bank.org/account/AZA12093" rel="self"/> <link rel="http://bank.org/rel/transfer edit" type="application/vnd.bank.org.transfer+xml" href="http://bank.org/transfers"/> <link rel="http://bank.org/rel/customer" type="application/vnd.bank.org.customer+xml" href="http://bank.org/customer/7t676323a"/> <balance currency="USD">993.95</balance> </account> <account> <id>ADK31242</id> 중략 </account></accounts>

Content-Type 으로 메세지의 형태를 정의

다음 상태로의 LINK 를 제공하여 상태 흐름을 정의Self descriptive message 구현


• STEP 3. AZA12093 계좌에서 ADK31242 계좌로 $100 를 계좌 이체한다 .REQUEST

URI http://bank.org/transfer

Method POST

PayLoad Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8<transfer xmlns="urn:org:bank:accounts"> <from>account:AZA12093</from> <to>account:ADK31242</to> <amount currency="USD">100</amount> <note>RESTing</note></transfer>

RESPONSE

HTTP Code 201 Created

Pay Load Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8 <transfer xmlns="urn:org:bank:accounts"> <link rel="self“ href="http://bank.org/transfer/XTA8763"/> <link rel="http://bank.org/rel/transfer/from" type="application/vnd.bank.org.account+xml" href="http://bank.org/account/AZA12093"/> <link rel="http://bank.org/rel/transfer/status" type="application/vnd.bank.org.status+xml" href="http://bank.org/check/XTA8763"/> <id>transfer:XTA8763</id> <amount currency="USD">100</amount> <note>RESTing</note></transfer>


• STEP 4. 하루가 지난후 계좌이체 결과를 조회

REQUEST

URI http://bank.org/check/XTA8763

Method GET

RESPONSE

HTTP Code 200 OK

Pay Load Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8 l;charset=UTF-8<status xmlns="urn:org:bank:accounts"> <code>01</code> <message xml:lang="en">Pending</message></status>

계좌 이체 진행중

5. Advanced REST

• Advanced REST 기능 Link 를 이용한 Resource 간의 관계 정의 Content-Type 을 이용한 Resource 의 메시지 형태 정의 Conditional GET 을 이용한 성능 향상 ETAG/Last Modified 를 이용한 동시 Update 방지 Stateless

5. Advanced REST

• Link– Resource 간의 관계를 정의– LINK 를 따라가면서 API 의 사용법을 알 수 있음 (Self-Descriptive)– Releation,URI,Content-Type 으로 구성됨

• Relation : Resource 간의 관계를 정의 ( 사람이 이해하기 쉬운 형태라야함 )• URI : 연관된 Resource 에 대한 URI• Content-Type: 해당 Resource 에 대한 데이터 포맷과 구조

– 표준안은 없고 논문에 따라 상당히 많은 표현 방법을 권장함

<link rel=“Relation” href=“http://URI” type=“Resource 의 포맷과 구조” /><link rel=“order” hfer=“http://example.org/order” type=“application/example.org.order+xml” />

< 관계 href=“http://URI” /><order href=“http://example.org/order” />

예제 1)

예제 2)

• 단순하고 이해하기 쉬움• 관계가 XML Element 로 표현되기 때문에 XML 스키마의 복잡도가 증가함• In/out message 에 대한 타입이 정의되지 않음 (HEAD 등을 이용하여 Query 하는 디자인이 필요 )

• 정형화된 형태로 실제 구현에 유리함• 가독성이 떨어짐• In/out message 에 대한 타입 정의가 모호함 (Resource 에 대한 데이터 타입은 원칙적으로 하나이지만 예외에 대한 대응 능력이 떨어짐 )

5. Advanced REST

• Content-Type Resource Data 에 대한 포맷 (XML,ATOM,JSON) 과 구조 ( 컬럼구조 ) 를

정의함 하나의 Resource 에 대해서 여러 데이터 포맷지원이 가능한 (Multiple

representation) HTTP Content-Type 헤더를 이용함 포맷 정의

• Content-Type:application/xml 형식으로 일반적으로 Content-Type 에 명기• 서버에 따라서 Content-Type 헤더를 인식 못하는 경우가 있음

– 이경우 X- 헤더를 사용하거나– URI 에 데이터 포맷을 명기할 수 있음 /product/321.xml , /product/321.json

구조 정의• Content-Type:application/org.example.order+xml 과 같이 Content-Type

에 명기하는 방안• Content-Type:application/xml + <order xmlns=“http://example.org/or-

der.xsd” /> 와 같이 Content-Type + XML Name Space 를 사용• 일반적인 형태에서는 구조를 정의 안하고 문서를 통해서 정의하여 배포하는

경우가 많음

5. Advanced REST

• Conditional GET– Web Proxy 를 이용하여 , 캐슁된 내용이 변경이 되지 않았으면 캐쉬 내용을

재활용하는 기술– 서버 성능과 자원사용의 효율성이 비약적으로 높아짐– Resource 에 대한 URI 가 유일하기 때문에 가능함– Last-Modified 헤더나 ETAG 헤더를 이용하여 구현 가능 ※ Resource 마다 Last-Modified 값을 관리해야 함

• Conditional GET with Last-Modified Header

Client REST

GET /partners/UK

200 OK Last-Modified: Sun, 21 Jan 2007 09:35:19 GMT[response]

GET /partners/UKIf-Modified-Since: Sun, 21 Jan 2007 09:35:19 GMT

304 Not Modified

Some time later

No content

5. Advanced REST

• Conditional GET with ETag

Client REST

GET /partners/UK

200 OKETag:”some UID”[response]

GET /partners/UKIf-None-Match:”some UID”

304 Not Modified

Some time later

No content

5. Advanced REST

• ETAG/Last Modified 를 이용한 동시 Update 방지– Etag 나 Last-Modified 헤더 이용– 동시에 두 사용자가 하나의 Resource 에 업데이트를 하여 데이터가 달라지는 문제를

방지

Client1 REST

GET /party/42200 OKETag:”some UID”[response]

POST /party/42ETag:”some UID”

412 Precondition not satisfied

Client2

POST /party/42ETag:”some UID”

GET /party/42

200 OKETag:”some UID”[response]

Update 가 끝난후 Etag 가 변경됨

예전 Etag 값으로 Update 를 요청했기 때문에412 에러를 내보냄

5. Advanced REST

• REST 보안– Authentication : APIKey(Public/Private Key 를 이용한 Handshake),

OAuth2 etc– Transport Layer : SSL ( 안전하지 않음 )– Message Level encryption 고려– HMAC 을 이용한 무결성 보장

• 메세지 전문에서 Private Key 를 가지고 , HMAC 생성 . (MD5,SHA1-256 등 사용 )

• 메세지 위변조 방지

– TimeStamp 를 이용한 ReplayAttack 방지HMAC (Key, ( 메세지 데이타 +timestamp) )

6. REST implementation

• Jersey– JSR-311 JAX-RS Reference Implementation (

https://jersey.dev.java.net/)– 장점

• 구현이 매우 쉬움 (Annotation 사용 )• Multiple contents representation (XML,JSON) 지원

– 단점• Advanced REST 의 모든 특징을 수용하기에는 부족함

– 특징• WAR 형태로 배포됨• JAXB 를 이용한 XML2JAVA Binding 사용 (VO 를 그대로 사용할 수 있음 )

• Node.JS– 자바스크립트 기반의 서버 엔진– Node.JS + Express(MVC) + MongoDB = 5~6 줄로 REST API 개발

https://jersey.dev.java.net/

6. REST implementation

URI

HTTP Method

Content-Type

Content-Type: Input Message Type

Content-Type : Output Message Type

Read Parameter from Query Stringhttp://example.org/resource?search=XX

URI

Read Parameter from URI http://example.org/resource/{container}

7. Reference Architecture of REST

• 전통적인 REST 구현체의 문제점 공통 기능의 중복 개발 단일 프로토콜만 지원 변화 ( 로직 , 전문 변화 ) 시 재구현이 필요함 낮은 유연성

• 해결 방안 REST 를 위한 Infrastructure 의 구축


• REST with ESB Architecture

Protocol Conversion

REST/XML WS XML RPC

Handling Cross cutting concern

Mediation Logic

SLA mgmt & Monitoring

REST/JSON

BusinessLogic

REST

BusinessLogic

REST

PLUG IN PLUG IN

RESTComponents

Enterprise Service Bus

Protocol Conversion REST/XML, REST JSON 등 다양항

프로토콜지원 URI 변환 , 헤더 처리

Cross Cutting Concern Logging,Billing,Security 등의 공통

기능 처리 Mediation Logic

Mash up, Function Adding 등의 REST 서비스 기능 변경

SLA Management & Monitoring Throttling, Alert, Status 모니터링 기능 제공


Enterprise Service Bus

Access Layer

ExternalEdge Proxy

CommonProxy

InternalEdge Proxy

REST Component

PartyResource

REST Component

OrderResource

LocalProxy

BusinessResource

LocalProxy

BusinessResource

LocalProxy

BusinessResource REST Component

ContentResource

Web

Serv

er

Consumer

Security Provider

Web Server

• REST with ESB Architecture


• ESB Architecture for REST

Edge Proxy

Common Proxy

Local Proxy

Business Resource

Generic ProxyMonitoring

Auditing

CCC-Logging

Alert

Throttling

SLA

Ignore

Reporting

CCC-Exception Handling

Auto retry

Human Error handling

OA

M

Secu

rity

Fram

ew

ork

Resource Application

Components

Orchestration Logic

Transformation

Compensation

Mediation

컴포넌트 기능 Proxy : Resource

Edge Proxy

프로토콜 변환

1:N

Common Proxy

공통 기능 수행 (Log-ging, 빌링 ,보안 )

1:N

Local Proxy

Mediation Logic 수행

1:1

Business Resource

SLA 및 모니터링

1:1


• Mash up in ESB

Enterprise Service Bus REST

REST

REST

Expose Layer

BusinessService

BusinessService

BusinessService

Open API

Open API

Open API

Access Layer

CommonProxy

EdgeProxy

Local ProxyService

Local ProxyService

Local ProxyService

MashupLocal Proxy

8. REST Stub generator

• REST 의 또다른 문제점– 클라이언트 STUB 이 없음 (WS 는 자동 STUB 이 있음 )– REST 서비스에 대한 메뉴얼을 만들어서 웹에 배포해야함

• 해결안– REST 소스코드를 자동 분석하여 CLIENT STUB 과 메뉴얼을 자동생성※ 요즘은 JSON Doc 을 만들어서 호출

JAX-RSSource Code

Parser(Qdox)

XML(Meta Info)

Client Stub Code

REST API Man-ual

(HTML)

XSLT(Style Sheet)

Velocity(Code Tem-

plate)

Generator Tool Kit


• REST Stub generator implementation sample

JAX-RSSource Code

Client Stub Code

REST API Man-ual

(HTML)


• Mapping Rule

Output Parameter

Resource name

Endpoint URI

Description

Method Summary||Method||EndpointURI||Http Method||Summary||

Endpoint URI Http method Response type

Description

Overview

Path parameter|| name || type || description ||

Query parameter|| name || type || required || description ||

Message payload

||element name || type || multiplicity|| description||

XML Scheme

Input Parameter

Header|| headerparam || type || required || description ||

Header|| headerparam || type || required || description ||

Message payload

||element name || type || multiplicity|| description||

XML Scheme

Http response code|| Http response code || description ||

Method

InputHttp-method :Endpoint-uri :Http header & valuesMessage Payload

OutputHttp-response codeHttp header & valuesMessage Payload

Sample

JAX-RS source code Meta Information

public void method(@HttpHeader (“x-REST-requestid”)String requestid

From JAXB code

From JAXB code

1..N1..1

We will use header with “HeaderConfigVo”will not support @HttpHeader annotation in this phase

Use Common Standard

Use Common Standard

9.REST Implementation considerations

• REST 아키텍쳐로 접근– 프로젝트에서 개발자들이 RPC 형태에 익숙해져 있음 – Operation 이나 Method 와 같은 행위 중심으로 설계에서 Resource

중심의 설계• DB 설계 고려

– Resource 가 DB 로 어떻게 Mapping 될것인가에 대한 사전 고려 필요– Primary Key 와 Resource ID (URI) 간의 연관 관계 고려– Alternative Key (AK) 고려– NoSQL (Document DB) 등 고려

• 캐쉬는 양날의 검– 웹의 특징을 잘 살리고 성능을 극대화 시킴– Last Modified 시간을 유지해야 함

• 전문 설계– REST 는 표준이 없기 때문에 , 내부 표준 전문 구현이 중요– 헤더에 어떤 데이타를 넣을것인지– HTTP Response Code 를 어떻게 사용할것인지 정의 필요

10. 현대의 REST 구현

• XML 보다는 JSON ( 당연히 )• HATEOS (HTTP Link) : http://projects.spring.io/spring-hateoas/• APIDocs & SandBox – Swagger• REST Test SOAPUI

SOAP UI Swagger

http://projects.spring.io/spring-hateoas/

http://projects.spring.io/spring-hateoas/

참고할만한 자료

• Stormpath.com API 디자인• APIgee.com API 디자인 가이드 문서

대용량 분산 아키텍쳐 설계 #5. rest

Engineering