REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.
위키백과
REST란?
REST는 프로토콜이나 표준이 아닌 아키텍처 원칙세트이다.
REST 디자인
1. 유니폼(균일한) 인터테이스
어떤 요청이 어디에서 오는지와 상관없이 동일한 자원을 요구하는 모든 API 요청은 동일하게 보여야 한다.
즉, 정해진 특정 정보를 요구하는 URI는 단 하나여야 한다.
2. 무상태성 (stateless)
RESTful API는 HTTP통신을 기반으로 함으로 무상태성을 가진다.
이는 곧 매 요청마다 필요한 모든 정보를 포함하여 보내야 한다.
3. 캐시 가능성 (Cacheable)
클라이언트 성능 향상 및 서버의 확장성을 위해 자원을 클라이언트 또는 서버측에서 캐싱할 수 있어야 한다.
4. 자체 표현 구조 (Self-descriptiveness)
REST에 사용되는 URI에 담겨있는 메세지만 보고도 이를 쉽게 이해할 수 있도록 해야한다.
5. 독립적 Client - Server 구조
RESTful한 구조에서는 클라이언트와 서버가 완전히 독립적이어야 한다.
통신에 있어서 클라이언트가 알아야 되는 건 요청할 리소스의 URI뿐이며, 다른 방법으로는 서버를 건드릴 수 없다.
서버 역시 클라이언트에게 간섭할 수 없으며 유일한 통신은 리소스를 전달하는 것 뿐이다.
6. 계층형 구조
REST 구조의 서버는 다중 계층으로 구성될 수 있으며, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
RESTful API의 작동 방식
RESTful API는 HTTP 요청을 통해 통신하여 특정 리소스의 정보들을 작성하고, 읽고, 업데이트하고, 삭제하는(CRUD라고 하는) 표준적인 데이터베이스 기능을 수행하게 된다.
RESTful API를 통해 요청이 수행될 때 RESTful API는 리소스 상태에 대한 표현을 요청자에게 전송한다.
이러한 정보의 표현은 JSON, HTML, PHP 등의 형식을 가지고 전송된다.
개중에 JSON은 사용언어에 큰 지장을 받지 않고 사람과 기계가 모두 읽을 수 있기에 가장 많이 사용되어 진다.
그럼 RESTful API를 어떻게 설계해야해?
RESTful API 설계시 가장 먼저 떠올려야 할 건 아래 두가지이다.
제품 리스트 페이지에서 제품 1을 지우기 위한 URI를 예로 들겠다.
1. URI는 정보의 자원을 표현해야 한다.
GET /products/delete/1 // ❌
GET /products/1 // ⭕️자원을 표현하는데 중점을 두어야 하며, delete과 같은 행위에 대한 표현을 URI내에 작성하는 것은 지양해야한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETTE)로 표현해야 한다.
그럼 위 예제와 같이 삭제와 같은 행위가 필요할 때는 어떻게 표현해야 할까?
DELETE /products/1바로 위와 같이 HTTP 메소드를 통해 표현하면 된다.
Path variable & Query parameter
Path variable
/products/3Path Varible은 경오를 변수로 사용하는 방법이다.
Query paramiter
/products?id=3기존의 경로 URL 뒤에 추가정보를 뒤에 붙여 서버 측에 전달하여 그에 맞는 요청을 받는 방법이다.
언제 사용하지?
어떤 리소스를 식별하여 처리를 할 경우 Path variable을 사용하고,
정렬 또는 필터링을 원한다면 Query parameter를 사용한다.
