Restful 하다는 것은 뭘까?

REST

- Representational State Transfer의 약자로, 아키텍쳐 스타일이다.

- 아키텍쳐 스타일 : 반복되는 아키텍쳐 디자인 

- 아키텍쳐 패턴 : 어떤 반복되는 문제 상황을 해결하는 도구

- 6가지 제약조건으로 구성되며, 이 가이드라인을 따르는 API를 RESTful API라고 한다.

 

REST 제약조건

- 클라이언트-서버

- 상태가 없음

- 캐시되는 데이터

- 일관적인 인터페이스

- 레이어 시스템

- 코드-온-디멘드(Optional)

 

 

1. 클라이언트-서버

- 리소스 : REST API가 리턴할 수 있는 모든 것을 의미. 예를들어 HTML, JSON, 이미지 등이 있다.

- 리소스를 관리하는 서버가 존재하고, 다수의 클라이언트가 리소스를 소비하려고 네트워크를 통해 서버에 접근하는 구조를 의미함.

 

2. 상태가 없음

- 클라이언트가 서버에 요청을 보낼 때, 이전 요청의 영향을 받지 않음을 의미한다.

- 예시

   : /login 요청을 보내고 로그인이 되어 다음 페이지인 /page로 넘어갔다고 가정하자. /page 리소스를 불러올 때 이전 요청에서 login한 사실을 서버가 알고 있어야 한다면 그것은 상태가 있는(stateful)한 아키텍쳐이다. 서버가 그 사실을 알지 못할 때 상태가 없음(stateless)이다.

   : 그럼 로그인을 어떻게 하라는 말인가? 또한 부득이한 경우 상태를 어떻게 유지해야하는가? 대답은 클라이언트가 서버에 요청을 할 때마다 요청에 리소스를 받기 위한 모든 정보를 포함해야한다는 것이다.

   : 로그인의 경우 서버는 로그인 상태를 유지하지 못하므로 요청을 보낼 때마다 로그인 정보를 항상 함께 보내야 한다. 리소스를 수정한 후 수정한 상태를 유지해야하는 경우에는 서버가 아닌 데이터베이스같은 퍼시스턴스에 상태를 저장해야 한다.

- HTTP는 기본적으로 상태없는 프로토콜이다. 따라서 HTTP를 이용하는 웹앱은 기본적으로 상태가 없는 구조를 따른다.

 

3. 캐시되는 데이터

- 서버에서 리소스 리턴 시 캐시가 가능한지 아닌지 명시가능해야한다. HTTP에서는 cache-control이라는 헤더에 리소스 캐시 여부를 명시할 수 있다.

 

4. 일관적인 인터페이스

- url의 일관성이 있어야 한다.

- 리턴 타입의 일관성이 있어야 한다.

- 리소스에 접근하는 방식, 요청 형식, 응답 형식, URL 등 형태가 앱 전반에 걸쳐 일관적이어야한다.

- 리턴 응답 시 해당 리소스를 수정할 수 있는 충분한 정보가 있어야 한다.ex) 아이디 값

 

5. 레이어 시스템

- 클라이언트가 서버에 요청 시 여러 개의 레이어로 된 서버를 거칠 수 있다.

- 서버 접속 시 인증, 캐싱, 로드 밸런서를 거쳐 앱에 도착한다고 가정 시 이 사이의 레이어들은 요청 및 응답에 어떤 영향을 미치지 않으며, 클라이언트는 서버 레이어 존재 유무를 알지 못한다.

 

6. 코드-온-디멘드

- 클라이언트는 서버에 코드를 요청할 수 있고, 서버가 리턴한 코드를 실행할 수 있다.

 

REST는 HTTP와는 다르다. REST는 HTTP를 이용해 구현하기 쉬우며, 대부분 HTTP를 이용해 구현한다.

REST는 아키텍쳐이고, HTTP는 프로토콜이다.