Rest(Representational state transfer) API

Rest란?

확장성 생성 언어(XML) 파일로 된 웹 페이지를 읽어 원하는 정보를 수집하는 기능.

웹 페이지를 만드는 사람은 주기적으로 내용을 개정하고

사용자는 그 페이지의 URL만 알면 웹 브라우저로 읽어 정보를 얻을 수 있다.

하이퍼텍스트 전송 규약(HTTP)과 XML을 포함한 웹 기술 및 프로토콜을 사용하는 구조적 형태로서

단순 객체 접근 프로토콜(SOAP)보다 사용이 간편하고, 사이트 내용을 기술하는 RSS(RDF Site Summary)의 정보 편집 기능과 유사하다.

RSS는 자원 기술 개념(RDF)을 사용한다.

Rest(Representational state transfer)를 있는 그대로 해석하면 표현을 통한 상태의 전이 라고 할수 있다.

여기서 표현이란 Http 요청 메시지와 거기에 해당하는 리소스의 내용을 전달하는 Http 응답 메시지로

간단히 설명하면 클라이언트와 서버간에 메시지로 서로의 상태변화를 공유하자는 것이다.

이런 Rest이론을 따르는 시스템구조를 Restful 시스템이라고 부른다.

 

Rest의 설계 원칙

1) 모든 자원은 URI(URL)로 관리

2) 클라이언트의 상태와 기능은 서버로 요청한 자원으로 파악

3) URI(URL)는 클라이언트와 서버 간의 자원을 가리키는 유일한 인터페이스

4) 클라이언트의 요청 정보는 서버에 저장되지 않음

 

서버내의 자원은 URL(Uniform Resource Locator) 혹은 URI(Uniform Resource Identifier)을 이용하여 관리한다.

 

URL 형식 : 서버 주소 + 서비스 이름+ 자원

장점

- URI(URL)형태로 자원을 관리 하기 떄문에 느슨한 결합(loose coupling)이 가능하며, 속도 또한 빠르다.

(URI(URL)형태로 자원을 관리 하기 떄문에 자주 사용하는 자원에 대해 캐싱 처리가 가능하다.)

- Http 프로토콜을 사용하여 패킷의 변화 없이 그래도 하용할수 있다.

- 결합도가 낮아 확장성이나 배포가 편리하다.

- 거의 모든 운영체제의 지원이 가능하며 별도의 라이브러리 배포없이 사용이 가능하다.

- 서버와 클라이언트의 역할이 독립되어 있어 변경이나 확장이 용이하다.

단점

- 공급자가 같더라도 서버별로 Rest API사이에 일관성이 없다.     

- Rest 모델에 적합하지 않은 형태의 URI(URL) 체계가 존재한다

- 표준화된 구성이나 정의가 없다.

Wikipedia: Representational state transfer