Your SlideShare is downloading. ×
REST Ovewview
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

REST Ovewview

10,226

Published on

This document introduces REST. …

This document introduces REST.
Explain about what is REST? and advanced REST feature.
It also introduce REST actual implementation with Jersey and REST infrastructure architecture with ESB based on actual delivery experience.
One more interest thing is that it has REST client stub generator & service contract generator design

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,226
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
315
Comments
0
Likes
10
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. REST Architecture Overview
    2009-07-10
    Oracle Principal Consultant
    Byungwook Cho (byungwook.cho@oracle.com)
  • 2. ICE Break
    REST
    Maldives!!
  • 3. ICE Break
    WebService
    Service Companies
    Open API
    Roy Fielding
    REST
  • 4. Agenda
    REST의 기원
    Basic of REST
    Basic REST example
    Advanced REST example
    Advanced REST
    REST Implementation
    Reference Architecture of REST
    REST Stub generator
    구현시 고려 사항
  • 5. 1. REST의 기원
    웹(HTTP)의 공동 창시자 Roy Fielding의 2000년 박사 논문에 소개 됨.
    기존의 웹이 HTTP의 장점을 100% 활용하지 못하고 있음
    네트워크 아키텍쳐 (Not a protocol)
    De facto Standard
    오픈 진영(Google ,Amazon) 에 의해서 주도됨
  • 6. 2. Basic of REST
    REST의 구성
  • 7. 2. Basic of REST
    Examples
    • 자바스터디 시스템에 이름이 “bcho”이 사용자를 생성
    • 8. 자바스터디 시스템에서 이름이 “bcho”이 사용자 정보를 조회
    • 9. 자바스터디 시스템에서 이름이 “bcho”인 사용자 정보를 변경
    • 10. 자바스터디 시스템에서 이름이 “bcho”인 사용자 정보를 삭제
    URI : http://www.javastudy.co.kr/users/bchoMethod : POST <user>  <name>조대협</name>  <email>bcho@bea.com</email> </user>
    Resource
    Action
    Message
    URI : http://www.javastudy.co.kr/users/bchoMethod : GET  
    URI : http://www.javastudy.co.kr/users/bchoMethod : PUT <user>  <name>조대협</name>  <email>bcho@bea.com</email> </user>
    URI : http://www.javastudy.co.kr/users/bchoMethod : DELETE  
  • 11. 2. Basic of REST
    Resource
    • Resource는 자원을 정의하며 각각 Unique한 URI를 갖는다.
    • 12. Select(GET)에 한하여 Query String을 이용하여 URI를 정의할 수 있다.
    • 13. Resource의 URI는 Human Readable한 포맷을 사용한다.
    • 14. Unique한 URI 사용으로 인해서 GET에 대해서 웹캐쉬 사용가능  비약적인 성능 향상
    http://example.org/products/1234
    http://example.org/user/scott
    http://example.org/account/XA123-345
    http://example.org/products?category=food
    권장 http://example.org/orders/2007/11
    권장하지 않는 사용법 http://example.org/ITGKA/XATTY
  • 15. 2. Basic of REST
    Action
    • HTTP Method를 이용하여 Resource에 대한 행위 (CRUD)를 나타냄
    • 16. 오래된 네트워크 장비나 서버의 경우 GET/POST만 허용
    • 17. HTTP 헤더 사용 x-http-method
    • 18. POST,GET,PUT,DELETE 만으로 표현하기 어려운 행위가 있음
    • 19. 행위를 재 정의 : 이메일을 보낸다  이메일을 생성한다.
    • 20. 제어의 의미나 기타 행위에 대해서는 내부적인 표준 마련  PUT : CONTROL
  • 2. Basic of REST
    Message
    GET으로 오는 리소스의 데이타를 표현
    UPDATE나 CREATE시에 전송되는 리소스의 데이타를 표현
    포맷
    XML 또는 JSON을 주로 사용 (표준은 없음)
    하나의 리소스에 대해서 여러가지 포맷을 동시 사용이 가능
    HTTP Content-Type 헤더로 정의 가능
    구조
    데이타의 컬럼 구조 (Scheme)를 정의
    REST에서는 구조를 정의하는 명시적인 방법이 없음 (CF. WebService/WSDL)
  • 21. 3. Basic REST example
    REST를 이용하여 계좌이체를 수행하는 애플케이션
    시나리오
    • STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다.
    • 22. STEP 2. 사용자 ID로 해당 사용자가 가지고 있는 계좌 목록을 조회한다.
    • 23. STEP 3. AZA12093계좌에서 ADK31242계좌로 $100를 계좌 이체한다.
    • 24. STEP 4. 이체된 결과를 확인한다.
  • 3. Basic REST example
    STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다.  로그인 했다고 가정
    STEP 2. 사용자 ID로 해당 사용자가 가지고 있는 계좌 목록을 조회한다
    사용자 ID
    두개의 계좌 정보가 리턴됨
  • 25. 3. Basic REST example
    STEP 3. AZA12093계좌에서 ADK31242계좌로 $100를 계좌 이체한다.
    계좌 이체 Transaction 이 생성됨
    계좌 이체 Transaction Id
  • 26. 3. Basic REST example
    STEP 4. 하루가 지난후 계좌이체 결과를 조회
    계좌 이체 진행중
  • 27. 4. Advanced REST example
    이것이 과연 REST?
    가장 기초중의 기초, 그럼 진짜 REST는?
    앞의 예제에서 누락된 HTTP의 특성
    LINK의 누락
    Link는 리소스간의 관계를 정의할 수 있다.
    Link를 통해서 리소스간의 BPM과 같은 Work-flow를 정의할 수 있다.
    Content-Type의 누락
    Input/Output Message Type을 정의할 수 있다.
  • 28. 4. Advanced REST example
    STEP 1. 사용자가 인터넷 뱅킹 시스템에 로그인을 한다.  로그인 했다고 가정
    STEP 2. 사용자 ID로 해당 사용자가 가지고 있는 계좌 목록을 조회한다
    Content-Type으로 메세지의 형태를 정의
    다음 상태로의 LINK를 제공하여 상태 흐름을 정의
    Self descriptive message 구현
  • 29. 4. Advanced REST example
    STEP 3. AZA12093계좌에서 ADK31242계좌로 $100를 계좌 이체한다.
  • 30. 4. Advanced REST example
    STEP 4. 하루가 지난후 계좌이체 결과를 조회
    계좌 이체 진행중
  • 31. 5. Advanced REST
    Advanced REST 기능
    • Link를 이용한 Resource간의 관계 정의
    • 32. Content-Type을 이용한 Resource의 메시지 형태 정의
    • 33. Conditional GET을 이용한 성능 향상
    • 34. ETAG/Last Modified를 이용한 동시 Update 방지
    • 35. Stateless
  • 5. Advanced REST
    Link
    Resource간의 관계를 정의
    LINK를 따라가면서 API의 사용법을 알 수 있음 (Self-Descriptive)
    Releation,URI,Content-Type으로 구성됨
    Relation : Resource간의 관계를 정의 (사람이 이해하기 쉬운 형태라야함)
    URI : 연관된 Resource에 대한 URI
    Content-Type: 해당 Resource에 대한 데이터 포맷과 구조
    표준안은 없고 논문에 따라 상당히 많은 표현 방법을 권장함
    예제 1)
    <link rel=“Relation” href=“http://URI” type=“Resource의 포맷과 구조” />
    <link rel=“order” hfer=“http://example.org/order” type=“application/example.org.order+xml” />
    • 정형화된 형태로 실제 구현에 유리함
    • 36. 가독성이 떨어짐
    • 37. In/out message에 대한 타입 정의가 모호함 (Resource에 대한 데이터 타입은 원칙적으로 하나이지만 예외에 대한 대응 능력이 떨어짐)
    예제 2)
    <관계 href=“http://URI” />
    <order href=“http://example.org/order” />
    • 단순하고 이해하기 쉬움
    • 38. 관계가 XML Element로 표현되기 때문에 XML 스키마의 복잡도가 증가함
    • 39. In/out message 에 대한 타입이 정의되지 않음 (HEAD 등을 이용하여 Query하는 디자인이 필요)
  • 5. Advanced REST
    Content-Type
    • Resource Data에 대한 포맷(XML,ATOM,JSON) 과 구조(컬럼구조)를 정의함
    • 40. 하나의 Resource에 대해서 여러 데이터 포맷지원이 가능한 (Multiple representation)
    • 41. HTTP Content-Type 헤더를 이용함
    • 42. 포맷 정의
    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/order.xsd” /> 와 같이 Content-Type + XML Name Space를 사용
    일반적인 형태에서는 구조를 정의 안하고 문서를 통해서 정의하여 배포하는 경우가 많음
  • 43. 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]
    Some
    time
    later
    GET /partners/UK
    If-Modified-Since: Sun, 21 Jan 2007 09:35:19 GMT
    304 Not Modified
    No content
  • 44. 5. Advanced REST
    Conditional GET with ETag
    Client
    REST
    GET /partners/UK
    200 OK
    ETag:”some UID”
    [response]
    Some
    time
    later
    GET /partners/UK
    If-None-Match:”some UID”
    304 Not Modified
    No content
  • 45. 5. Advanced REST
    ETAG/Last Modified를 이용한 동시 Update 방지
    Etag나 Last-Modified 헤더 이용
    동시에 두 사용자가 하나의 Resource에 업데이트를 하여 데이터가 달라지는 문제를 방지
    REST
    Client1
    Client2
    GET /party/42
    200 OK
    ETag:”some UID”
    [response]
    GET /party/42
    200 OK
    ETag:”some UID”
    [response]
    POST /party/42
    ETag:”some UID”
    Update가 끝난후 Etag가 변경됨
    POST /party/42
    ETag:”some UID”
    예전 Etag값으로 Update를 요청했기 때문에
    412 에러를 내보냄
    412 Precondition not satisfied
  • 46. 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를 그대로 사용할 수 있음)
  • 47. 6. REST implementation
    URI
    HTTP Method
    Content-Type
    URI
    Content-Type: Input Message Type
    Content-Type : Output Message Type
    Read Parameter from Query String
    http://example.org/resource?search=XX
    Read Parameter from URI
    http://example.org/resource/{container}
  • 48. 7. Reference Architecture of REST
    전통적인 REST 구현체의 문제점
    • 공통 기능의 중복 개발
    • 49. 단일 프로토콜만 지원
    • 50. 변화 (로직,전문 변화)시 재구현이 필요함  낮은 유연성
    해결 방안
    • REST를 위한 Infrastructure의 구축
  • 7. Reference Architecture of REST
    REST with ESB Architecture
    • Protocol Conversion
    • 51. REST/XML, REST JSON등 다양항 프로토콜지원
    • 52. URI 변환, 헤더 처리
    • 53. Cross Cutting Concern
    • 54. Logging,Billing,Security등의 공통 기능 처리
    • 55. Mediation Logic
    • 56. Mash up, Function Adding 등의 REST 서비스 기능 변경
    • 57. SLA Management & Monitoring
    • 58. Throttling, Alert, Status 모니터링 기능 제공
    REST/JSON
    REST/XML
    WS
    XML RPC
    Protocol Conversion
    Enterprise
    Service Bus
    Handling Cross cutting concern
    Mediation Logic
    SLA mgmt & Monitoring
    PLUG IN
    PLUG IN
    REST
    REST
    REST
    Components
    Business
    Logic
    Business
    Logic
  • 59. 7. Reference Architecture of REST
    REST with ESB Architecture
    Consumer
    http://www.rest.com/social
    http://www.rest.com/social/users/profile
    http://openapi.rest.com/social/users/profile
    http://openapi.rest.com/social
    /OpenAPI/REST/v1.0
    http://www.rest.com/OpenAPI/REST/v1.0/social/users/profile
    REST Component
    Enterprise Service Bus
    Order
    Resource
    Security Provider
    Access Layer
    Business
    Resource
    Local
    Proxy
    External
    Edge Proxy
    REST Component
    Common
    Proxy
    Party
    Resource
    Business
    Resource
    Local
    Proxy
    Internal
    Edge Proxy
    Business
    Resource
    Local
    Proxy
    REST Component
    Content
    Resource
    /InterAPI/REST/v1.0
    http://openapi.rest.com/InterAPI/REST/v1.0/social/users/profile
  • 60. 7. Reference Architecture of REST
    ESB Architecture for REST
    Resource Application
    CCC-Logging
    Generic Proxy
    Monitoring
    Edge Proxy
    Auditing
    Mediation
    Orchestration Logic
    Common Proxy
    Transformation
    Compensation
    Security
    Framework
    OAM
    SLA
    Alert
    Local Proxy
    Throttling
    CCC-Exception Handling
    Ignore
    Reporting
    Business
    Resource
    Auto retry
    Human Error handling
    Components
  • 61. 7. Reference Architecture of REST
    Mash up in ESB
    Enterprise Service Bus
    REST
    Expose Layer
    Open API
    Business
    Service
    Local Proxy
    Service
    Access Layer
    REST
    Business
    Service
    Common
    Proxy
    Edge
    Proxy
    Local Proxy
    Service
    Open API
    Business
    Service
    Local Proxy
    Service
    REST
    Mashup
    Local Proxy
    Open API
  • 62. 8. REST Stub generator
    REST의 또다른 문제점
    클라이언트 STUB이 없음 (WS는 자동 STUB이 있음)
    REST 서비스에 대한 메뉴얼을 만들어서 웹에 배포해야함
    해결안
    REST 소스코드를 자동 분석하여 CLIENT STUB과 메뉴얼을 자동생성
    JAX-RS
    Source Code
    Parser(Qdox)
    Client Stub Code
    Velocity(Code Template)
    XML
    (Meta Info)
    REST API Manual(HTML)
    XSLT
    (Style Sheet)
    Generator Tool Kit
  • 63. 8. REST Stub generator
    REST Stub generator implementation sample
    REST API Manual(HTML)
    JAX-RS
    Source Code
    Client Stub Code
  • 64. 8. REST Stub generator
    Mapping Rule
    1..N
    1..1
    Resource name
    Method
    Overview
    Endpoint URI
    Endpoint URI
    Http method
    Response type
    Description
    Description
    Method Summary
    ||Method||EndpointURI||Http Method||Summary||
    Input Parameter
    Use Common Standard
    Header
    || headerparam || type || required || description ||
    Path parameter
    || name || type || description ||
    Query parameter
    || name || type || required || description ||
    Message payload
    ||element name || type || multiplicity|| description||
    From JAXB code
    XML Scheme
    Output Parameter
    Use Common Standard
    Header
    || headerparam || type || required || description ||
    Message payload
    ||element name || type || multiplicity|| description||
    From JAXB code
    XML Scheme
    Http response code
    || Http response code || description ||
    Sample
    Input
    Http-method :
    Endpoint-uri :
    Http header & values
    Message Payload
    Output
    Http-response code
    Http header & values
    Message Payload
    public void method(@HttpHeader (“x-REST-requestid”)String requestid
    We will use header with “HeaderConfigVo”will not support @HttpHeader annotation in this phase
    JAX-RS source code
    Meta Information
  • 65. 9.구현시 고려사항
    REST 아키텍쳐로 접근
    프로젝트에서 개발자들이 RPC 형태에 익숙해져 있음
    Operation이나Method와 같은 행위 중심으로 설계에서 Resource 중심의 설계
    DB설계 고려
    Resource 가 DB로 어떻게 Mapping 될것인가에 대한 사전 고려 필요
    Primary Key와 ResourceID (URI)간의 연관 관계 고려
    Alternative Key (AK) 고려
    캐쉬는 양날의 검
    웹의 특징을 잘 살리고 성능을 극대화 시킴
    Last Modified 시간을 유지해야 함
    전문 설계
    REST는 표준이 없기 때문에, 내부 표준 전문 구현이 중요
    헤더에 어떤 데이타를 넣을것인지
    HTTP Response Code를 어떻게 사용할것인지 정의 필요
  • 66. Thank you
    For more information please visit my blog.
    http://bcho.tistory.com

×