REST
Representational State Transfer의 약자로서 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처 스타일.
- HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD연산을 적용하는 것
- 자원 기반의 구조(ROA, Resource Oriented Architecture)설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처.
* URL vs URI
-
- URL: Uniform Resource Locator로, 인터넷 상 자원의 위치를 의미함.
- URI: Uniform Resource Identifier로, 인터넷 상의 자원을 식별하기 위한 문자열의 구성(URI는 URL을 포함)
* CRUD Operation
-
- Create(생성): POST
- Read(조회): GET)
- Update(수정): PUT
- Delete(삭제): DELETE
REST 특징
- Uniform Interface(인터페이스 일관성)
- 일관성있는 인터페이스로 URI를 통해 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.
- HTTP 표준 프로토콜만 따른다면 모든 플랫폼(특정 OS/Language에 종속된 것이 아닌)에서 사용이 가능
- Client-server(클라이언트-서버 구조)
- 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트로 동작하는 구조를 갖음.
- REST서버는 API를 제공하고, 클라이언트는 사용자 인증, Context(세션, 로그인 정보 등)을 직접 관리.
- 클라이언트와 서버의 역할이 구분되어 개발 내용이 명확해지고 의존성이 줄어듬
- Stateless(무상태)
-
- 서버는 단순히 요청에 대한 응답만 보낼 뿐, 세션 유지 관리는 클라이언트에게 책임이 있음.
- 클라이언트의 context(세션, 쿠키 등의 정보)를 서버에 저장하지 않기 때문에 구현이 단순.
- 서버는 클라이언트의 각각의 요청을 이전 상태 정보를 참고 하지 않고 매 요청을 별개의 것으로 인식해서 처리(→ 서버의 Response가 일관성있게 이루어지고 그만큼 서비스의 자유도가 높아짐.)
→ Stateless의 장점
-
- 클라이언트의 요청의 세션 상태를 저장할 필요할 필요가 없으므로 구현이 간소화 되고 그만큼 API를 여러 서버에 배포하고 확장하는 데 도움이 됨.
- 클라이언트가 각 요청과 함께 서버의 처리에 필요한 모든 정보를 전송하기 때문에 클라이언트의 정보를 단순 처리함.
- 서버측에서 메모리 사용량을 줄일 수 있고, 세션이 필요하지 않으므로 세션관리가 불필요.
- Cacheable(캐시 가능)
-
- REST의 가장 큰 특징 중 하나는 HTTP 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있음
- HTTP의 캐싱 기능을 적용 가능하므로 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현 가능.
- Layered System(계층화 시스템)
-
- 클라이언트와 서버가 분리되어 중간에 프록시 서버, 게이트웨이, 암호화 계층 등 중간 매체를 사용해 자유도를 높일 수 있음.
- 클라이언트는 API만 호출하므로 서버와 직접 통신하는 것인지 중간 매체 서버와 통신하는지 알 수 없음.
- Self-descriptiveness(자체 표현 구조)
-
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 구성되어 있음.
REST API vs RESTful API
* API: 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
- REST API: REST 아키텍쳐 스타일을 따르는 API
- RESTful API: 위에서 살펴본 REST의 기본 원칙들을 잘 지켜서 설계된 API
REST의 구성 요소
- Resource(자원): URI를 의미함. 클라이언트는 URI를 이용해 자원을 지정하고 해당 자원 상태(정보)에 대한 조작을 서버에 요청함.
- Verb(행위) HTTP Method(GET, POST, PUT, DELTE ..)
- Representation(표현): 서버와 클라이언트가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS등이 있고 주로 JSON, XML를 통해 데이터를 주고받음.
REST API 디자인 가이드
- URI는 자원의 정보를 표현해야 한다.
- 자원에 대한 행위는 HTTP Method로 표현하되, Method는 URI에 포함하지 않는다.
REST의 장단점
장점
- REST API 사용을 위해 별도의 인프라 구축 필요X
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능
- REST API 메시지가 의도하는 바를 직관적으로 이해할 수 있음
- server, client를 완전히 독립적으로 구현할 수 있음
- 뛰어난 유연성, 낮은 유지 보수 비용, 높은 확장성, 사용 간단 등
단점
- 표준이 존재하지 않아 별도의 정의가 필요함.
- 일부 구형 브라우저가 아직 지원해주지 못하는 부분이 존재함.(익스플로어)
- HTTP Method를 사용하지만 사용할 수 있는 메소드 숫자와 형태가 제한적임.
REST API 설계 규칙
- URI(리소스 이름)는 명사를 사용한다.(URI는 어떤 정보의 자원을 표현해야한다.)
- 슬래시로 계층 관계를 표현한다.
- 자원의 행위는 HTTP Method로 표현한다.
- URI의 마지막 문자로 슬래시를 표함하지 않는다.
- 밑줄을 사용하지 않고 하이픈( -)을 사용한다.
- URI는 소문자로만 구성한다.
- 파일 확장자는 URI에 포함하지 않는다.
예시
/users/me/profile (O)
/users/me/profile/ (X)
/users/me/profile-preview (O)
/users/me/profilePreview (X)
/users/me/picture -Accept: image/png (O)
/users/me/picture.png (X)