Rest API

REST: Restpresentational State Transfer

아키텍처 스타일: 반복되는 아키텍처 티자인

REST 6가지 제약조건

1. 클라이언트-서버
   1. 클라이언트-서버: 리소스(REST API가 리턴할 수 있는 모든 것 ex: HTML, JSON, 이미지 등)를 관리하는 서버가 존재하고 다수의 클라이언트가 리소스를 소비하려고 네트워크를 통해 서버에 접근하는 구조  
2. 상태가 없는 stateless
   1. 상태가 없다: 클라이언트가 서버에 요청을 보낼 떄 이전 요청의 영향을 받지 않음
   2. HTTP: 기본적으로 상태가 없는 프로토콜
   3. 로그인 예시 - 클라이언트는 서버에 요청을 할 때마다 요청에 리소스를 받기 위한 모든 정보를 포함해야 한다. 서버는 로그인 상태를 유지하지 못하므로, 요청을 보낼 때마다 로그인 정보를 항상 함께 보내야 한다.
   4. 리소스를 수정한 후 수정한 상태를 유지해야 하는 경우에는 서버가 아닌 데이터베이스가 같은 퍼시스턴스에 상태를 저장해야한다.
3. 캐시되는 Cacheable 데이터
   1. 서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 한다.  HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있다.
4. 일관적인 인터페이스 Uniform Interface
   1. 일관적인 인터페이스라는 것은 시스템 또는 애플리케이션의 리소스에 접근할 때 인터페이스가 일관적이야 한다.
   2. 리소스에 접근하는 방식, 요청 형식, 응답 형식, URI, 요청의 형태와 응답의 형태가 애플리케이션 전반에 걸쳐 일관적이어야 한다는 것이 방침
   3. 서버가 리턴하는 응답에는 해당 리소스를 수정할 수 있는 충분한 정보가 있어야 한다.
5. 레이어 시스템 Layered System
   
   1. 클라이언트가 서버에 요청을 할 때 여러 개의 레이어로 된 서버를 거칠 수 있다. 
   2. 서버가 인증 서버, 캐싱 서버, 로드 밸런서를 거쳐서 최종적으로 애플리케이션에 도착한다고 가정, 이 사이의 레이어들은 요청과 응답에 어떤 영향을 미치지 않으며 클라이언트는 서버의 레이어 존재 유무를 알지 못한다.
6. 코드-온-디멘드 Code-On-Demand(선택사항)
   1. 클라이언트는 서버에 코드를 요청할 수 있고 서버가 리턴한 코드를 실행할 수 있다.
   2. REST는 HTTP와 다르다. REST는 HTTP를 이용해 구현하기 쉽고 대부분 그렇게 구현하지만 엄밀히 말하면 REST는 아키텍처이고, HTTP는 REST 아키텍처를 구현할 떄 사용하면 쉬운 프로토콜이다.