[ Rest API ] REST 아키텍처의 제약 사항

---

RESTful API 의 제약 사항

---

REST 아키택처의 제약 조건을 준수하는
웹 서비스 API 를
RSETful API 라고 부른다.

---

클라이언트 - 서버

• 이 제약사항은 관심사의 분리에 관한 것이다. 클라이언트 - 서버 아키택처 스타일에서 사용자 인터페이스에 대한 관심사는 데이터 저장소의 관심사와 분리하는 것이다. 웹 애플리케이션은 이 스타일에 적합하다.
• 프런트엔드는 브라우저 내부에 클라이언트로 존재하며 클라이언트는 API 를 통해 서버와 통신한다.
• 잘 알려진 또 다른 아키택처 스타일은 이벤트 기반의 통합 아키택처이다.
• 시스템 구성요소는 네트워크를 통해 이벤트를 전송하고 동시에 관심이 있는 이벤트를 수신한다.

 

무상태성

• 클라이언트와 서버 간의 통신은 무상태성 ( Stateless )  를 가진다.
• 클라이언트에서 서버로의 각 요청은 서버가 해당 요청을 이해하는 데 필요한 모든 정보를 포한한다.
• 해당 서버는 요청을 완전히 이해하는데 저장된 컨텍스트를 이용해서는 안된다.

 

캐시

• 이 제약 사항은 시스템의 성능에 관련된 것이며, 그 시스템에서 요청에 대한 응답에 암묵적 또는 명시적으로 캐시 가능 또는 불가능을 알려줄 수가 있어야 한다.
• 웹 애플리케이션은 응답에서 Cache-Control ETag, ETag, Expires 와 같은 HTTP 헤더를 사용해 캐시를 제어할 수 있다.

 

유니폼 인터페이스

• 이 제약 사항은 REST 아키택처 스타일을 SOAP 과 같은 다른 스타일과 구별하는 중심 기능이다.
• 유니폼 인터페이스를 이용해 전반적인 시스템의 아키텍쳐가 단순화되고 상호작용의 가시성이 향상된다.
• 유니폼 인터페이스를 얻는 데는 네 가지 인터 페이스 제약 사항이 있다.
  • 리소스 식별
  • 표현을 통한 리소스 조작
  • 자기 서술 메세지
  • 애플리케이션 상태의 엔진으로서의 하이퍼미디어 등 

 

계층형 시스템

• 계층형 아키텍처 또한 일종의 관심사에 대한 분리다.
• 계층화 된 시스템의 아키텍처는 구성 요소의 동작을 제한하는 계층으로 구성되어 각 구성 요소가 상호작용하는 밀접한 계층 너머로는 볼 수가 없다.

 

주문형 코드 ( Code-On-Demond )

• 이 제약사항은 REST 아키택처 스타일에서 선택 사항이다.
• 로이 필딩에 따르면, REST 는 애플릿 또는 스크립트 형태로 코드를 다운로드 하고 실행함으로써 클라이언트 기능을 확장할 수 있게 한다.
• 이는 미리 구현되야 하는 기능의 수를 줄임으로써 클라이언트를 단순화 한다.
• 실제로 런타임 중에는 많은 RESTful API 가 코드를 다운로드 하고 실행하지 않도록 허용하지 않는다.
• 시스템이 이전 제약 사항을 준수하는 한 RESTful 이라고 할 수 있다.
• 대부분 RESTful API 가 HTTP 를 통해 구축 되지만, HTTP 가 시스템이 RESTful 을 충족하도록 만드는 필수 요소는 아니다.
• 대부분 HTTP 는 공개 표준으로써 HTTP API 구현이나 클라이언트 구현을 특정 기술에 바인딩 하지 않기 때문이다.
• HTTP 에 익숙한 개발자는 RESTful API 를 쉽게 선택할 수 있다.

---