REST(REpresentational State Transfer) API

REST is a way of prividing interoperability between computer systems on the Internet.

REST API는 로이 필딩이 자신의 논문(Architectural Sytles and the Design of Network-based Foftware Architectures)에서 처음으로 거론한 아키텍쳐이다. 

로이필딩의 HTTP/1.0명세 제작에 참석했도 하위 버전과의 호환성을 위한 고민을 하던 중 HTTP Object Model을 고안했고 이게 나중에 REST란 이름으로 논문으로 발표된다.

REST API는 아키텍쳐 스타일 이면서 하이퍼 아키텍쳐 스타일이다->아키텍쳐 스타일 이면서 아키텩쳐 집합이다.

    REST는 프로토콜이나 표준이 아닌 아키텍쳐 원칙 세트이다. RESTful API를 통해 요청이 수행될때 RESTful API는 리소스 상태에 대한 표현을 요청자에게 전송한다. 이 정보는 JSON, HTML, XLT, 일반 텍스트를 통해 전송된다 

  API가 RESTful하기 위해서는 다음 기준을 준수해야 한다.

  1. Client-serve model: 클라이언트, 서버, 리소스로 구성되 있고 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍쳐이다. 

  2.  stateless client-server communication

  3. Cache: 클리아언트-서버 상호작용을 간소화 하는 캐시 기능

  4. 정보가 표쥰 형식으로 전송되기 위한 구성요소 간 통합 인터페이스(uniform interface).

       4.1 Identification of resosurce: 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되야 한다.

       4.2 Maniplation of resources through representations: 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 한다.

       4.3 Self-description message: 클라이언트에 반환되는 자기 기술적(self-descriptive)메시지에 클라이언트가 정보를 어떠게 처리할지 설명하는 정보가 충분해야한다.

       4.4 hypermedia as the engine of application state(HATEOAS): 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기카 모든 작업을 찾을 수 있어야한다.

   5. Layered system: 요청된 정보를 검색하는 데 관련된 서버의 각 유형을 클라이언트가 볼 수 없는 구조로 체계화하는 계층화된 시스템

  6. code on demand(optional): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송해 클라이언트 기능을 확장할 수 있는 기        능(Java script).

위의 것들을 모두 만족하면 RESTful하다고 할 수 있다. 여기서 1, 2, 3, 5는 사실 HTTP만 제대로 사용하면 지킬 수 있다.

진짜 문제가 되는 부분은 4.3, 4.4이다.

Self-description message는 그 메시지 만으로도 원하는 정보를 얻을 수 있는 메시지이다. 이를 위해서는 메시지가 반드시 Host헤더를 통해 Host를 명시하고 Content-type을 정의해야 한다. 

HATEOAS는 application 상태가 Hyperlink만으로 전이가 되야한다 라는 의미를 가지고 있고 html이 이를 만족한다(예: a tag).

 

API가 RESTful하지 않는 이유는 사람-기계의 통신이 아닌 기계-기계의 통신이기 때문이다. API는 HTML이 아닌 JSON을 주고 받는다. 이때 JSON은 hyperlink를 지원하지 않고 self-description을 불완전 하게 만족한다. 이는 JSON이 문법은 있으나 그 내부에 무엇이 들거갈지를 저의하고 있지 못하기 때문이다. 예를 들어 HTML에는 각 태그에 사용되는 프로퍼티를 레퍼런스가 정의하고 있지만 JSON은 key:value꼴에서 key와 value를 정확히 정의하지 못하고있다.

 

self-description, HATEOAS는 클라이언트, 서버의 독립적 진화에 도움이 된다.

self-description: 확장 가능한 커뮤티케이션이 가능. 메시지 만으로 원하는 정보를 얻을 수 있으므로

HATEOAS: 애플리케이션 상태 전이의 late binding-> 어떤 상태로 전이가 완료되서야 그 다음 전이가 될 수 있는 상태가 결정된다.

->링크는 동적으로 변경된다.

 

REST API는  결국 호환성을 위해 고안된 것이다. 실제로 HTTP는 호환성에 대한 엄청난 집착으로 구성되 있다.

예를 들어:

1. Referer->오타인데 수정을 안한다

2. charset->잘못 지은 이름인데 수정을 안한다.

3.HTTP/0.9를 크롬, 파이어 폭스가 아직도 지원한다.

API에 대한 설명은 다음 링크를 참고

iskull-dev.tistory.com/71

API(Applicatino Programming Interface)