서버 클라이언트 간의 통신을 효율적이게 하기 위한 아키텍쳐 스타일.

HTTP 위에서 동작하며, HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 자원(Resource: URI)과 행위(Verb: HTTP Method)로 표현하여 특정한 형태(Representations)로 전달하는 방식 이다.

Rest Api 특징.

Uniform Interface (균일한 or 일관된 인터페이스)
Uniform Interface라는 특징은 RESTful 시스템 설계의 기본이다.
아키텍쳐를 단순화하고 분리하여, 각 부분이 독립적으로 발전 할 수 있도록 하는데 이때 Uniform Interface의 네가지 제약은 아래와 같다.
(1) Resource identification in requests
(2) Resource manipulation through representations
(3) Self-descriptive messages (자체적인 설명이 되는 메시지)
각 메시지는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어 있어야 한다.
(4) Hypermedia as the engine of application state

Stateless (무상태성)
상태정보를 따로 관리하지 않고 단순히 API 서버로 들어오는 요청만을 처리하면 된다.
이는 서비스의 자유도가 높아지게 해주며, API 서버에 불필요한 정보를 관리하지 않게 되므로 구현에도 용이하다.

Cacheable (캐시가능)
HTTP 기존의 웹 표준을 사용하므로 HTTP 프로토콜 기반의 로드밸런서(mod_proxy), SLL, 캐싱 기능을 적용 가능.

Client-Server Architecture (서버-클라이언트 구조)
REST API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다.
일반적으로 서버는 API를 제공하고, 클라이언트는 그 정보를 사용하는 다른 역할(사용자 인증, 세션 관리, 로그인 정보 관리 등..)을 함으로써 역할의 구분을 통해 의존성을 줄인다.

Layered System (계층 구조)
클라이언트는 서버와 직접 통신하는지, 서버 앞의 중간 서버와 통신하는지 알 수 없다.
'클라이언트 요청 > Rest API (데이터 조회)'처럼 사용되는 것처럼 보일 수 있다.
하지만 '클라이언트 요청 > Rest API (프록시 서버 > 로드 밸런싱 > 암호화 > 데이터 조회)'처럼 더 많은 다양한 계층을 거칠 수도 있다.

Stateless 란??

stateless : server side에 client와 server의 동작, 상태정보를 저장하지 않는 형태, server의 응답이 client와의 세션 상태와 독립적임

이에 따른 불편한 점 -->
쿠키와 세션으로 극복

쿠키는 브라우저에 있는 저장소이다. 헤더에 해당 값을 보내면 되기에 상태를 유지하게 된다.

세션은 서버 저장소를 사용하는 것으로 서버 값을 가지게 되므로 상태를 가지게 된다. 해당 서버와만 통신이 가능하기에 scale out 이 안돼(가능하지만 복잡)