RESTful

출처 : 

https://helloreallplay.wordpress.com/2012/07/17/restful-%EC%9D%B4%EB%9E%80/

https://jungseob86.wordpress.com/2014/03/08/restful-%EC%9D%B4%EB%9E%80/

http://blog.remotty.com/blog/2014/01/28/lets-study-rest/

https://ko.wikipedia.org/wiki/REST

RESTful 이란?

REST라는 개념을 Skillcrush라는 곳에서는 아래와 같이 정의하고 있다.

REST is a set of simple rules for how to organise and transmit information on the internet.

REST 은 Representational State Transfer의 줄임말로써 표현 가능한 상태 전송 이라는 의미를 가지고 있으며 네트워크 시스템의 아키텍처 스타일을 말한다. 보통 네트워크 시스템 아키텍처라고 하면 클라이언트 / 서버 구조를 떠올리는데, REST는 여기서 파생된 아키텍처 스타일이다. 이 용어는 로이 필딩 (Roy Fielding )의 박사학위 논문에서 소개되었다.

• 엄격한 의미 : REST는 네트워크 아키텍처 원리의 모음이다. (여기서 '네트워크 아키텍처 원리'란 리소스를 정의하고 리소스의 주소를 지정하는 방법 전반)

• 간단한 의미 : 웹상의 리소스를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 간단한 인터페이스를 말한다.

위의 두가지 의미는 서로 겹치거나 충돌되는 부분이 있는데 이 형식을 통하면 HTTP나 www가 아닌 아주 거대한 소프트웨어 시스템을 설계하는 것도 가능하며 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다.

필딩의 REST 원리를 따르는 시스템은 자주 Restful이란 용어로 지칭된다.

- 좀 더 쉬운 설명

HTTP URI를 통해 리소스를 명시하고, HTTP Method ( Post, Get Put, Delete )를 통해 해당 리소스에 대한 CRUD Operation을 적용한다. 즉 REST는 ROA ( Resource Oriented Architecture ) 설계의 중심에 리소스가 있고 HTTP Method를 통해 리소스를 처리하도록 설계된 아키텍처를 의미한다.

- HTTP Method - CRUD Operation

[ POST -- Create ]
[ GET -- Read ]
[ PUT -- Update ]
[ DELETE -- Delete ]

- Example ( Twitter )

https://api.twitter.com/1.1/statuses/retweets/21947795900469248.json
위의 주소를 Get Method로 요청하면 21947795900469248 를 Source 로 rewtweet된 최근 100개의 tweet 정보를 반환할 것이다.
Post Method로 요청하면 21947795900469248 를 Source로 retweet 할 것이다.

REST 의 주요한 목표

• 구성 요소의 상호작용의 규모 확장성 ( scalability of component interactions )
• 인터페이스의 범용성 ( Generality of interfaces )
• 구성 요소의 독립적인 배포 ( Independent deployment of components )
• 중간 구성요소를 이용해 응답 지연 감소, 보안 강화, 레거시 시스템을 인캡슐레이션 (Intermediray components to reduce latency, enforce security and encapsulate legacy systems)

REST 아키텍처에 적용되는 6가지 제한 조건

• 클라이언트 / 서버구조 : 일관적인 인터페이스로 분리되어야 한다.

• 상태없는 (Stateless) : 각 요청 간 클라이언ㅌ트의 컨텍스트가 서ㅓ에 저장되어서는 안된다.

• 캐시 처리 가능한 (Cacheable) : www 에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다. 잘 관리되는 캐싱은 클라이언트 - 서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 확장성(scalability)과 성능을 향상시킨다.

• 계층화 ( Layered System ) : 클라이언트는 보통 대상 서버에 직접 연결되었는지 또는 중간서버를 통해 연결되었는지 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템규모 확장성으 로학장시키는데 유용하다.

• Code on demand ( optional ) : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 잇는 로직을 전송하여 기능을 확장 시킬수 있다.

• 인터페이스 일관성 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple) 함으로써 클라이언트 - 서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

REST 인터페이스의 원칙에 대한 가이드

- 자원의 식별

요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI 사용을 예로 들수 있다. 리소스 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터 베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.

- 메세지를 통한 리소스의 조작

클라이언트가 어떤 자원을 지칭하는 메세지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경, 삭제할 수 있는 충분한 정보를 가지고 잇는 것이다.

- 자기서술적 메세지

각 메세지는 자신을 어떻게 처리해야하는지에 대한 충분한 정보를 포함해야한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메세지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야 할 지 알 수 있어야 한다. 메세지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메세지는 자기 서술적이 아니다.

- 애플리케이션의 상태에 대한 엔진으로서 하이퍼 미디어

만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 잇어야 한다. 충분한 컨텍스트 속에서 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

REST 의 장점

• Open API를 제공하기 쉽다.
• 멀티 플랫폼 ( Web, IOS, Android ) 지원 및 연동이 용이하다.
• 원하는 타입 ( json, xml, rss ..) 으로 데이터를 주고 받을 수 있다.
• 기존 웹 인프라 ( HTTP ) 를 그대로 활용할수 있다. (방화벽 문제에서 자유롭고, 로드밸런서 등의 장비도 그대로 이용가능)
• 리소스가 유니크한 URI로 표현되도록 설계하면 웹 캐시 서버도 이용가능
• 쉽다.

REST 의 단점

• 사용할 수 있는 Method 가 4가지 밖에 없다. 즉 CRUD로 표현하기 모호한 작업을 처리하기 애매하다.
• HTTP 의존적이다. (요즘은 아니라고 한다.)
• 표준이 없어 관리가 어렵다.

※ 통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다.

• 프로토콜 (HTTP 혹은 FTP) + : + // + 호스트이름 + 주소
• 예: http://ko.wikipedia.org