REST 구성
- 자원(Resource): URI
- 행위(Verb): HTTP METHOD
- 표현(Representations)
6가지 원칙
- URI로 지정한 리소스에 대한 조작을 한정적인 인터페이스로 수행하는 것을 의미합니다.
Stateless
- REST는 무상태성을 갖습니다. 즉, 상태에 대한 정보를 따로 저장하고 관리하지 않는다는 말입니다.
- 세션이나 쿠키 정보를 별도로 저장하지 않고, API서버는 들어오는 요청만 단순히 처리하면 됩니다.
- 이는 구현을 단순하게 만들어줍니다.
Caching
- 이는 REST의 가장 큰 특징 중 하나입니다.
- HTTP라는 기존 웹표준을 그대로 사용하기때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있습니다.
- 따라서 HTTP의 캐싱 기능을 사용할 수 있습니다.
- E-Tag나 Last-Modified 태그를 이용하면 캐싱 구현이 가능해집니다.
Client-Server
- REST 서버는 API 제공, 클라이언트는 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하는 구조로 역할이 확실히 구분됩니다.
- 서버에서 개발할 내용과 클라이언트에서 개발해야 할 내용의 구분이 확실해지면서, 서로의 의존성이 줄어들게 됩니다.
Hierarchical System
- REST는 레이어 계층의 시스템입니다.
- 각 컴포넌트들은 자신과 상호작용하는 계층에 대한 지식이 없다는 것입니다.
- 이는 코드들이 독립적이며, 대체가능하거나 확장 가능하다는 것으로 이어질 수 있습니다.
Code on demand
- 코드는 클라이언트가 그 기능을 확장할 수 있도록 다운로드 가능하여야한다는 말입니다. 하지만 이는 선택적인 요소입니다.
RESTful하게 API를 디자인한다는 것은?
- 리소스와 행위를 명시적이고 직관적이게 분리해야 합니다.
- 리소스는 URI로 표현되는데, 리소스가 가리키는 것은 명사로 표현되어야 합니다.
- 즉, URI는 정보의 자원을 표현해야 합니다.
- 행위는 HTTP METHOD로 표현되며, GET, POST, PUT, PATCH, DELETE가 있습니다.
- 즉, 자원에 대한 행위는 HTTP METHOD로 표현합니다.
- Message는 Header와 Body를 명확히 분리해서 사용해야 합니다.
- Entity에 대한 내용은 Body에 담습니다.
- 애플리케이션 서버의 행동의 판단 근거가 되는 컨트롤 정보인 API 정보, 응답받고자 하는 MIME 타입 등은 header에 담습니다.
- 헤더와 바디는 http header와 http body로 나눌 수도 있으며, http body에 들어가는 json 구조로 분리할 수도 있습니다.
- API 버전을 관리합니다.
- 특정 API를 변경할 때에는 반드시 하위호환성을 보장해야 합니다.
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 합니다.
- 브라우저는 form-data 형식의 submit, 서버에서는 json 식으로의 분리보다는 하나로 통일하도록 합니다.
- 즉, URI가 플랫폼 중립적이어야 한다는 말입니다.
RESTful API의 장점은?
- OPEN API를 제공하기 쉽다.
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
단점은?
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에는 부적합하다.
- HTTP 통신 모델에 대해서만 지원한다.
