REST

What is REST? — (2)

<PREV 

 



REST 6 Constraints

Uniform Interface

Uniform Interface Constraints는 REST Design에서 가장 기본적인 Contraint이다.
이는 개발하고자하는 Architecture를 간단히 하고 Client와 Server를 분리하여 각각 독립적으로 진화하여 전개될 수 있게 한다.

즉, 통일된 Interface를 통해, 어떠한 기술(Phython, PHP, C#, Ruby, Java)이든 어떠한 Platform(iOS, Android, Mac, Windows)이든 상관없이 사용할 수 있다.





Uniform Interface는 크게 4가지로 설명되어질 수 있다.

  • Resource Indentifier
  • Resource Representations
  • Self-Descriptive Message
  • HASTOEAS (Hypermedia AS The Engine Of Application State)
- Resource Identifier (URI)

일반적으로 Resource는 Service나 Information을 제공하는 모든 것들(ex - Order, Invoice, Set of rows in a DB, Collectin of seach results, etc.)이 될 수 있으며, WEB 상에서 Addressable(=Client와 Server 사이에서 접근될 수 있고 전송될 수 있는)해야 한다.
즉, Resource는 하나 이상의 유일한 특정 주소인 URI(Uniform Resource Indentifer)를 반드시 가져야 한다. REST에서는 Resource를 특징짓을 수 있는 동사형(Verb)이 아닌 명사형(Noun) Indentifier로 URI를 정의하도록 권장하고 있으며, WEB 상에서 URL(Uniform Resource Locator)를 통해 제한된 Methord와 함께 접근될 수 있다.

Resources in REST

REST에서, Resources는 Entities(실체)와 유사하나, 어떤 결과물(result sets)은 아니다. REST에서 Resource는 두개의 주요 type으로 정의되기를 권장한다.

  • Collections : ex> users/
  • Itmes : ex> users/teddy
URL vs URI

URL은 URI의 한 부분으로 Network Lacation에 대한 정보 즉 Resouce에 대해 어떻게 접근하는지에 대한 Path이다.
URI는 Clients와 Servers를 간 Resource의 Representation을 교환하기 위한 유일한 방법으로, 시간이 흘러도 변하지않는 주소 정보를 포함한 Identifier이다.





- Resource Representation

Client-Server 구조에서 Resouce를 직접 주고 받는 것이 아니라, 그 Resource에 대한 상태나 정보를 설명(대표)하는 Representation을 주고 받는다. Resource는 하나 이상의 Representation을 가질 수 있으며, 해당 Representation의 형태는 content-type으로 결정되며, Client 마다 동일한 Resouce에 대해 다른 Representation을 가질 수 있다.

  • Representation Formats
    • text/html
    • application/xml
    • application/json
    • application/x-www-form-urlencoded (for input: PUT,POST)
    • Others : image(svg,jpg,png,etc.), txt/css, text/javascript




Resource는 Unique Id로 하나 이상의 URI 뿐만 아니라, 다양한 방법으로 설명(대표)되는 Representation을 가질 수 있다. 또한 Representation에 대한 접근을 위한 URL을 가지고, HTTP 4 가지 Method (POST/GET/PUT/DELETE)을 통해 생성, 조희, 갱신, 삭제될 수 있다.





- Self-Descriptive message & API

REST는 State를 유지하지 않는 특징을 가지고 있으므로, Client-Server 간 Message는 충분히 자신에 대한 State나 정보등을 설명할 필요가 있다. 이를 위해서 REST Message는 요청 작업을 완료할 수 있도록 또는, 그 Resonpse를 이해할 수 있도록 충분한 정보들을 HTTP method, HTTP status code, HTTP Header등을 활용하여 전달하거나 전달되어야 한다.

또 다른 관점으로는, Server가 제공하는 REST API는 그 스스로가 무엇을 하는 것인지 별다른 문서없이 충분히 설명되어야져 한다는 것이다.

REST API는 URI와 HTTP method와 함께 Resource를 Collection & Item으로 계층적으로 표현함으로써 어떠한 기능을 수행하고 어떠한 결과(HTTP Status Code)를 내는지 쉽게 파악할 수 있도록 구성하여야 한다.

Resource GET PUT POST DELECT
http://example.com/resoources/ Collection에 속한 자원들의 목록 조회 다른 Collection으로 교체 해당 Collection을 생성 전체 Collection을 삭제
http://example.com/resources/item17/ item17에 대한 자원 조회 item17 수정 item17에 귀속된 새로운 자원 생성 item17 삭제
HTTP Status Code Descriptions
200 성공
400 Bad Request - field validation 실패시
401 Unauthorized - API 인증,인가 실패
404 Not found
500 Internal Server Error - 서버 에러

REST API Design Guide refer to as below
http://bcho.tistory.com/914

- HASTOEAS

Hypermedia As The Engine Of Application State

  • Use links to allow client to discover locations and operations
  • Link relations are used to express options
  • Clients do not need to knows URLs
  • This controls the state

HATEOAS 메시지를 보내는 것은 어플리케이션의 상태를 변화시킨다.
하이퍼미디어의 특징을 이용하여 HTTP Response에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴하는 것이다.
예를 들어 앞서 설명한 페이징 처리의 경우, 리턴시, 전후페이지에 대한 링크를 제공한다거나,연관된 리소스에 대한 디테일한 링크를 표시 하는 것등에 이용할 수 있다.

조회 예제
{  
    users : 
    [  
        {  
            "id":"user1",
            "name":"terry"
        },
        { 
            "id":"user2",
            "name":"carry"
        }
    ],
    "links":
    [  
        {
            "rel":"pre_page",
            "href":"http://xxx/users?offset=6&limit=5"
        },
        {
            "rel":"next_page",
            "href":"http://xxx/users?offset=11&limit=5"
        }
    ]
}

관계 표현 예제
{  
    "id":"terry",
    "links":
    [  
        {  
        "rel":"friends",
        "href":"http://xxx/users/terry/friends"
        }
    ]
}
저작자 표시 동일 조건 변경 허락
신고

REST

What is REST? — (1)



Introduction

REpresentional State Tranfter의 약자로 2000년도 웹(HTTP)의 공동 창시자인 Roy Fielding의 박사 논문에 소개되었다. REST는 기존의 Web-Service들이 HTTP를 적극적으로 활용하지 못하는 문제를 해결하기 위해서 제안되었다. 얼핏보면 HTTP를 대체하는 Protocol처럼 인식되나, REST는 결코 Protocol이 아니다. HTTP를 보다 HTTP답게 만들기 위한 방법론 즉, Network based Software Architecture를 위한 Architectural Style & Design 이다. 많은 사람들이 REST를 마치 SOAP(Simple Obeject Acess Protocol)과 같이 WEB Application의 Protocol로 착각하는 경우가 많은데, REST는 WEB Application의 동작 원리와 그 동작의 효율을 설명하는 Design Paradigm 이다.

REST는 철저히 Resource 중심적 설계를 중시하고, Create / Read / Update / Delete (CURD)에 해당하는 HTTP의 4 가지 Method POST / GET / PUT / DELECT 를 그 용도에 맞게 정확하게 사용함으로써, 기존의 Service 중심의 Web Application(SOA - Service, Verbs 중심)을 Resource 중심의 Web Application(ROA - Resource, Nouns)으로의 변화를 일으켰다.

REST는 Protocol이 아닌 설계론이라는 것을 이해하자. 이러한 REST Architecture에 맞게 설계된 Design을 “RESTful”이라 표현하기도 한다.

REST는 오늘날 Google, Amazon, Flicker, Tweeter와 같은 Open Service 업체들의 주도 하에 적극 적용되어, 표준 아닌 표준 Defecto Standard로 자리를 잡아가고 있다.


REST 6 Constraints

Web이나 Application이 다음의 6가지 조건을 만족하게 설계되었다면 “REST(ful)하게 설계했다”라고 말할 수 있다.

  • Client-Server
  • Stateless
  • Cacheable
  • Layered System
  • Code on demand (optional)
  • Uniform Interface

REST를 특징짓을 수 있는 6 가지 조건에 대해 간략하게 알아 보자.

Client-Server

Client를 Server로부터 분리하는 것이다.
예로, Client로 하여금 Server가 관리하고 저장하는 Data들에 무관심하게 만들어서, 서버 의존적인 Client code를 좀 더 자유롭게하여 이동성(Portability)를 향상시킨다. 즉 Server와 Client 간의 역할 분담을 명확히 하고 서로 분리하여 Server와 Client의 자율도를 높힌다.

REST Server는 그러한 Resouece를 관리하는 API를 제공하며, Client는 사용자 인증이나 Context(Session, Login 정보)등을 직접 관리하고 책임진다. Server는 Client의 User Interface나 User State에 상관없이 Server 기능에 집중할 수 있어, 보다 간단하게(Simplicity), 보다 쉽게(Scalable) 확장될 수 있다.





Stateless

REST의 가장 대표적인 특징이라 하겠다. 이전과 이후에 대한 직접적인 정보가 필요없이 직관적으로 REST Server가 제공하는 API를 통해 Resource에 접근한다. 즉 세션정보와 같은 Context를 저장할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이라든지 기타 유연한 아키텍처의 적용이 가능하다.

단, Client는 자신을 구분하기 위해 정보를 서버에게 충분히 전달해야 한다.(API Key or Token)





Cacheable

REST는 HTTP 기반의 Web protocol을 그대로 활용하기 때문에 기존 Web이 가지는 특징들을 그대로 가질 수 있다.
HTTP 프로토콜 기반의 Load balance나 SSL, HTTP가 가진 가장 강력한 특징중의 하나인 Caching 기능을 적용할 수 있다. Web Service에서 60% ~ 80% 가량의 Transcation이 조회(GET) Transaction인 것을 생각한다면, Stateless Server의 무수한 Resource들을 Web-Chache server, Proxy server 나, Client 등에 직접 Caching 하는 것은 많은 장점이 있다는 것을 쉽게 알 수 있다.
구현은 HTTP 프로토콜 표준에서 사용하는 “Last-Modified” 태그나 E-Tag를 이용하면 Cache를 구현할 수 있다.





Client-Cache-Sateless-Server

REST의 3가지 특징 Client-Server, Stateless, Cache를 아래 그림으로 잘 표현되어 있다.





Layered System

Layered System 역시 Cacheable 특징처럼 HTTP의 특징을 그대로 활용할 수 있다.
System Scaling을 위해 Gateway, Proxy server, Firewall 과 같은 또 다른 Layer들을 수용할 수 있다.





Code on Demand (Optional)

Server는 실행가능한 코드 (Executable Code)를 Client에게 전송해줌으로써, Client의 기능들을 일시적으로 확장하거나 커스터마이징 할 수 있다. Java Applet이나 JavaScript 등이 대표적인 예라 하겠다.
Server는 Client의 Resource Request에 대하여 Resource와 함께 JavaScript와 같은 code를 함께 Return 하여 Client의 기능 확장과 설정을 할 수 있어, 사용자 인식에 대한 성능 및 효과를 높힐 수 있다.





Uniform Interface

Uniform Interface Constraints는 REST Design에서 가장 기본적인 Contraint이다.
이는 개발하고자하는 Architecture를 간단히 하고 Client와 Server를 분리하여 각각 독립적으로 진화하여 전개될 수 있게 한다.

즉, 통일된 Interface를 통해, 어떠한 기술(Phython, PHP, C#, Ruby, Java)이든 어떠한 Platform(iOS, Android, Mac, Windows)이든 상관없이 사용할 수 있다.





Uniform Interface는 크게 4가지로 설명되어질 수 있다.

  • Resource Indentifier
  • Resource Representations
  • Self-Descriptive Message
  • HASTOEAS (Hypermedia AS The Engine Of Application State)
- Resource Identifier (URI)

일반적으로 Resource는 Service나 Information을 제공하는 모든 것들(ex - Order, Invoice, Set of rows in a DB, Collectin of seach results, etc.)이 될 수 있으며, WEB 상에서 Addressable(=Client와 Server 사이에서 접근될 수 있고 전송될 수 있는)해야 한다.
즉, Resource는 하나 이상의 유일한 특정 주소인 URI(Uniform Resource Indentifer)를 반드시 가져야 한다. REST에서는 Resource를 특징짓을 수 있는 동사형(Verb)이 아닌 명사형(Noun) Indentifier로 URI를 정의하도록 권장하고 있으며, WEB 상에서 URL(Uniform Resource Locator)를 통해 제한된 Methord와 함께 접근될 수 있다.

Resources in REST

REST에서, Resources는 Entities(실체)와 유사하나, 어떤 결과물(result sets)은 아니다. REST에서 Resource는 두개의 주요 type으로 정의되기를 권장한다.

  • Collections : ex> users/
  • Itmes : ex> users/teddy
URL vs URI

URL은 URI의 한 부분으로 Network Lacation에 대한 정보 즉 Resouce에 대해 어떻게 접근하는지에 대한 Path이다.
URI는 Clients와 Servers를 간 Resource의 Representation을 교환하기 위한 유일한 방법으로, 시간이 흘러도 변하지않는 주소 정보를 포함한 Identifier이다.





- Resource Representation

Client-Server 구조에서 Resouce를 직접 주고 받는 것이 아니라, 그 Resource에 대한 상태나 정보를 설명(대표)하는 Representation을 주고 받는다. Resource는 하나 이상의 Representation을 가질 수 있으며, 해당 Representation의 형태는 content-type으로 결정되며, Client 마다 동일한 Resouce에 대해 다른 Representation을 가질 수 있다.

  • Representation Formats
    • text/html
    • application/xml
    • application/json
    • application/x-www-form-urlencoded (for input: PUT,POST)
    • Others : image(svg,jpg,png,etc.), txt/css, text/javascript




Resource는 Unique Id로 하나 이상의 URI 뿐만 아니라, 다양한 방법으로 설명(대표)되는 Representation을 가질 수 있다. 또한 Representation에 대한 접근을 위한 URL을 가지고, HTTP 4 가지 Method (POST/GET/PUT/DELETE)을 통해 생성, 조희, 갱신, 삭제될 수 있다.





- Self-Descriptive message & API

REST는 State를 유지하지 않는 특징을 가지고 있으므로, Client-Server 간 Message는 충분히 자신에 대한 State나 정보등을 설명할 필요가 있다. 이를 위해서 REST Message는 요청 작업을 완료할 수 있도록 또는, 그 Resonpse를 이해할 수 있도록 충분한 정보들을 HTTP method, HTTP status code, HTTP Header등을 활용하여 전달하거나 전달되어야 한다.

또 다른 관점으로는, Server가 제공하는 REST API는 그 스스로가 무엇을 하는 것인지 별다른 문서없이 충분히 설명되어야져 한다는 것이다.

REST API는 URI와 HTTP method와 함께 Resource를 Collection & Item으로 계층적으로 표현함으로써 어떠한 기능을 수행하고 어떠한 결과(HTTP Status Code)를 내는지 쉽게 파악할 수 있도록 구성하여야 한다.

Resource GET PUT POST DELECT
http://example.com/resoources/ Collection에 속한 자원들의 목록 조회 다른 Collection으로 교체 해당 Collection을 생성 전체 Collection을 삭제
http://example.com/resources/item17/ item17에 대한 자원 조회 item17 수정 item17에 귀속된 새로운 자원 생성 item17 삭제
HTTP Status Code Descriptions
200 성공
400 Bad Request - field validation 실패시
401 Unauthorized - API 인증,인가 실패
404 Not found
500 Internal Server Error - 서버 에러

REST API Design Guide refer to as below
http://bcho.tistory.com/914

- HASTOEAS

Hypermedia As The Engine Of Application State

  • Use links to allow client to discover locations and operations
  • Link relations are used to express options
  • Clients do not need to knows URLs
  • This controls the state

HATEOAS 메시지를 보내는 것은 어플리케이션의 상태를 변화시킨다.
하이퍼미디어의 특징을 이용하여 HTTP Response에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴하는 것이다.
예를 들어 앞서 설명한 페이징 처리의 경우, 리턴시, 전후페이지에 대한 링크를 제공한다거나,연관된 리소스에 대한 디테일한 링크를 표시 하는 것등에 이용할 수 있다.

조회 예제
{  
    users : 
    [  
        {  
            "id":"user1",
            "name":"terry"
        },
        { 
            "id":"user2",
            "name":"carry"
        }
    ],
    "links":
    [  
        {
            "rel":"pre_page",
            "href":"http://xxx/users?offset=6&limit=5"
        },
        {
            "rel":"next_page",
            "href":"http://xxx/users?offset=11&limit=5"
        }
    ]
}

관계 표현 예제
{  
    "id":"terry",
    "links":
    [  
        {  
        "rel":"friends",
        "href":"http://xxx/users/terry/friends"
        }
    ]
}

 

 

 

NEXT> 

저작자 표시 동일 조건 변경 허락
신고

7 inch display board with WizFi210

by MCSElec



Overview

This post show the UDP connection with the WizFi210 and Android phone. You can show the same displays with your smartphone on 7 inch touch-screen. Using your smart phone, you can controll and monitors your home device such as light, temperature, and humidity.

The MCSElec explains how to use WizFi210 and 7 inch touch screen on this post.

How to use WizFi210

Hardware
  • WIZFI210 Wireless network
  • GPS ITRAX300 GPS
  • BTM220 Class 1 bluetooth
  • Bluegiga WT41 1 kilometer bluetooth
  • SCP1000 barometer
  • DS1337 clock with battery backup
  • RS232
  • Alvidi AVRB Atxmega128A1 module
  • 7 inch display
  • FT232RL USB
Source code

Include a PDF-file for the 7 inch display and some pictures for the Alvidi on-board SD-card : Download Ssd1963_7inch.zip

DS1338-33 clock

Put a DS1338-33 clock IC on the board. It is the 3,3 volts 1307.
Got some help to get soft I2c running, the command $forcesofti2c did the trick. And if you study the history.txt files of the Bascom-AVR updates, you will find this command.

WizFi210

HKipnik made an example how to make an UDP connection between the 7 inch display board and a Android SmartPhone.

To configure the WIZFI210 with WPA or WEP key, with DHCP or fixed IP and to have it auto-connect a level converter RS232 from PC straight to the WIZFI210.

Bascom, Android and Wireless, all credit goes to HKipnik alias HKBascom alias Heiko.

Demo Movies

Learn more

Goto Original


저작자 표시 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바