REST(Representational State Transfer)는 아키텍처 스타일이다.
아키텍처 스타일은 아키텍처 패턴과는 조금 다른데, 패턴은 어떤 반복되는 문제 상황을 해결하기 위한 도구이고 스타일은 반복되는 아키텍처 디자인을 의미한다. REST 아키텍처 스타일은 6가지 제약 조건으로 구성되고 이 가이드라인을 따르는 API를 RESTful API라고 한다.
REST 제약 조건
- 클라이언트 - 서버
- 상태가 없는(stateless)
- 캐시 가능한 데이터
- 일관적인 인터페이스
- 레이어 시스템
- 코드 온-디맨드(선택사항)
클라이언트 - 서버
리소스를 관리하는 서버가 존재하고, 다수의 클라이언트가 리소스를 소비하기 위해 네트워크를 통해 서버에 접근하는 구조를 의미한다.
- 리소스란 REST API가 리턴할 수 있는 모든 것을 의미한다. ex)HTML, JSON, 이미지 등
상태가 없음(stateless)
클라이언트가 서버에 요천을 보낼 때, 이전 요청의 영향을 받지 않음을 의미한다.
클라이언트는 서버에 요청을 날릴 때마다 요청에 리소스를 받기 위한 모든 정보를 포함해야 한다.
- HTTP는 기본적으로 상태가 없는 프로토콜이다. 그래서 HTTP를 사용하는 웹 애플리케이션은 기본적으로 상태가 없는 구조를 따른다.
캐시 가능한 데이터
서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 한다. HTTP에서는 cache-control이라는 헤더에 리소스의 캐시 여부를 명시할 수 있다.
일괄적인 인터페이스
시스템 또는 애플리케이션의 리소스에 접근하기 위한 인터페이스가 일관적이어야 한다는 뜻이다. 리소스에 접근하는 방식, 요청의 형식, 응답의 형식이 애플리케이션 전반에 걸쳐 URI, 요청의 형태와 응답의 형태가 일관적이어야 한다.
레이어 시스템(Layered System)
클라이언트가 서버에 요청을 날릴 때, 여러 개의 레이어로 된 서버를 거칠 수 있다. 이 사이의 레이어들은 요청과 응답에 어떤 영향을 미치지 않으며 클라이언트는 서버의 레이어 존재 유무를 알지 못한다.
코드-온-디맨드(Code-on-Demand)
클라이언트는 서버에 요청할 수 있고, 서버가 리턴한 코드를 실행할 수 있다.
- REST는 HTTP와 다르다. REST는 아키텍처이고, HTTP는 REST 아키텍처를 구현할 때 사용하면 쉬운 프로토콜이다.
