REST API

REST는 Respesentational State Transfer의 약자로 아키텍처 스타일이다.

아키텍처 스타일은 아키텍처 패턴과는 조금 다르다.

아키텍처 패턴은 어떤 반복되는 문제 상황을 해결하는 도구고, 아키텍처 스타일은 반복되는

아키텍처 디자인을 의미한다.

REST아키텍처 스타일은 6가지 제약조건으로 구성된다. 이 가이드 라인을 따르는 API를 

RESTful API라고 한다.

REST 제약조건

• 클라이언트-서버
• 상태가 없음
• 캐시되는 데이터
• 일관적인 인터페이스
• 레이어 시스템
• 코드-온-디맨드(선택사항)

  ---

클라이언트 - 서버

클라이언트 - 서버라는 것은 리소스를 관리하는 서버가 존재하고, 다수의 클라이언트가

리소스를 소비하려고 네티워크를 통해 서버에 접근하는 구조를 의미한다. 

이런 구조 중 우리에게 가장 친숙한 것이 바로 웹 애플리케이션이고 우리가 

만들려는 Todo 앱도 클라이언트 - 서버 구조다.

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

---

상태가 없음

상태가 없다는 것은 클라이언트가 서버에 요청을 보낼 때 이전 요청의 영향을 받지 않음을 의미한다.

예를 들어 /login으로 로그인 요청을 보내고 로그인이 돼 다음페이지인 /page로 넘어갔다고 가장하자

/page로 리소스를 불러올 때 이전 요청에서 login한 사실을 서버가 알고 있어야 한다면, 그것은

상태가 있는 아키텍처다.

서버가 그 사실을 알지 못한다면 상태가 없는 것이다. 그럼 로그인을 어떻게 하란말인가.?

리소르를 수정한 후 수정한 상태를 유지해야 하는 경우에는 서버가 아닌 데이터베이스 같은 퍼시스턴스

상태를 저장해야한다.

HTTP는 기본적으로 상태가 없는 프로토콜이다. 따라서 HTTP를 사용하는 웹 어플리케이션은 기본적으로 상태가 없는 구조를 따른다.

---

캐시되는 데이터

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

리소스의 캐시여부를 명시 할 수 있다.

---

일관적인 인터페이스

일관적인 인터페이스라는 것은 시스템 또는 애플리케이션의 리소스에 접근할 때 인터페이스가 일관적이어야 한다는 뜻이다.

또 서버가 리턴하는 응답에는 해당 리소스를 수정할 수 있는 충분한 정보가 있어야 한다.

예를 들어 해당 아이템을 받아왔는데 ID가 없다면 이후 클라이언트는 해당 아이템을 업뎃이나 삭제를하지 못한다.

리소스를 수정하는데 충분한 정보가 있어야한다.

---

레이어 시스템

클라이언트가 서버에 요청을 할 때 여러 개의 레이어로 된 서버를 거칠 수 있다. 예를 들어 서버가 인증서버, 

캐싱서버, 로드 밸런서를 거쳐서 최종적으로 애플리케이션에 도착한다고 가정하자,

이 사이 레이어들은 요청과 응답에 어떤 영향을 미치지 않으며 클라이언트는 서버의 레이어 존재 유무를

알지 못한다.

---

코드-온-디멘드

이 제약은 선택사항이다. 클라이언트는 서버에 코드를 요청할 수 있고, 서버가 리턴한 코드를 실행할 수 있다.

REST는 HTTP와 다르다. REST는 HTTP를 이용해 구현하기 쉽고 대부분 그렇게 구현하지만 엄밀히 말하면 REST는 아키텍처이고, HTTP는 REST 아키텍처를 구현할 때 사용하면 쉬운 프로토콜이다.