해당 글은 DEPth IT 연합 프로젝트 동아리 활동의 일환인 서버 스터디에 관련되어 있습니다.🐧
REST
REST는 분산 하이퍼 미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식입니다. 기본적으로 웹의 의존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 활용 가능합니다. 자원을 이름으로 구분하여서 해당 자원의 상태를 주고 받는 모든것을 의미합니다.
HTTP URL을 통해서 자원을 명시하고, HTTP Method를 통해서 해당 자원에 대한 CRUD operation을 적용하는 것을 의미합니다.
웹 사이트의 모든 자원에 고유한 ID인 URL을 부여합니다. 이후 HTTP Method를 통해서 리소스를 처리합니다.
장점
- HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구축하지 않아도 됩니다.
- HTTP 프로토콜을 따르는 모든 플랫폼에서 사용이 가능합니다.
- REST API가 의도하는 바를 명확하게 나타내므로 쉽게 파악이 가능합니다.
- 서버와 클라이언트의 역할을 명확하게 분리합니다.
단점
- 표준이 존재하지 않습니다.
- HTTP 메서드가 제한적입니다.
- Header 값 사용이 URL을 바로 사용하는 것보다 진입장벽이 존재합니다.
구성요소
자원: URL
- 모든 자원에는 고유한 ID가 존재하고, 해당 자원은 서버에 존재합니다.
- 자원을 구별하는 ID는 HTTP URL입니다.
- 클라이언트는 URL을 통해서 자원을 특정하고, 해당 자원에 대한 조작을 서버에 요청합니다.
행위: HTTP Method
- HTTP 프로토콜의 메서드를 사용하여 클라이언트가 자원에 대한 조작을 서버에 요청합니다.
- 하나의 자원에 대한 응답을 여러 형태로 나타내어 질 수 있지만 주로 JSON, XML을 사용합니다.
특징
Server-Client 구조
자원이 있는 쪽이 서버, 자원을 요청하는 곳이 클라이언트입니다. 서로 의존성이 줄어드는 구조입니다.
Stateless
클라이언트의 context를 서버에 저장하지 않습니다. 따라서 쿠키나 세션과 같은 정보를 신경쓰지 않아도 되어서 구현이 단순화됩니다. 또한 서버는 각각의 요청을 별개의 것으로 인식합니다. 이전 요청이 다음 요청에 연관되지 않습니다. 따라서 자유도가 높아집니다.
계층화
클라이언트는 REST API 서버만 호출합니다. API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 암호화, 사용자 인증등을 추가하여서 구조상의 유연성을 줄 수 있습니다. 게이트웨와 같은 네트워크 기반의 중간 매체를 사용할 수 있습니다.
인터페이스 일관성
HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능합니다. URL로 지정된 리소스에 대한 조작을 한정된 인터페이스로 수행합니다.
RESTful API
REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있습니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됩니다.
이러한 RESTful API를 구현하는 목적은 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기입니다.
Rest Controller
스프링에서 컨트롤러를 지정해주는 어노테이션은 @Controller 와 @RestController가 존재합니다.
@Controller는 Model 객체를 만들어 데이터를 담고 View를 반환합니다.
@RestController는 단순히 객체만 반환하고 객체 데이터는 JSON 혹은 XML 형식으로 HTTP 응답에 담아 전송합니다.
둘은 HTTP Response Body가 생성되는 방식이 다릅니다. RestController는 Controller에 @ResponseBody가 추가된 것입니다.
아래와 같은 방식으로 작동합니다.
