•
이 장에서 배우는 내용
◦
스프링 MVC에서 REST 엔드포인트 정의하기
◦
하이퍼링크 REST 리소스 활성화하기
◦
레포지터리 기반의 REST 엔드포인트 자동화
•
동적인 페이지가 등장하면서 기존의 정적인 페이지들은 거의 사라졌다. 동적인 페이지의 효율적인 구성을 위해 프론트와 백의 구분이 생겼으며 백엔드는 html 파일을 보내는 대신 REST API를 제공한다.
1. REST 컨트롤러 작성하기
•
기존의 스프링 MVC의 MPA에서 프론트의 SPA를 사용하게 되는 경우, 표현 계층이 백엔드의 처리와 거의 독립적이므로 의존성이 낮아진다.
◦
이런 유연성을 확보하는 대신 복잡성을 얻게 되었다. 단순히 정보를 표시하는 것이 목적이라면 MPA를 사용하는 것이 적합하다. 관리자 페이지와 같은 것들 말이다.
•
REST API를 정의하는 경우에도 @GetMapping, @PostMapping과 같은 매핑 어노테이션들은 여전히 사용된다.
1. 서버에서 데이터 가져오기
•
@RestController는 다음 두 가지를 지원한다.
◦
@Controller나 @Service와 같이 스테레오타입 어노테이션이므로 이 어노테이션이 지정된 클래스를 스프링의 컴포넌트 스캔으로 찾을 수 있다.
◦
HTTP Response Body에 직접 쓰는 값을 반환하는 것임을 스프링에게 알려준다.
▪
@Controller를 사용하는 경우, Response Body에 직접 쓰는 값을 반환함을 알려주려면 @ResponseBody 어노테이션을 지정해야 한다.
▪
이외에도 ResponseEntity 객체를 반환하는 방법이 존재한다.
2. 하이퍼미디어 사용하기
•
기존의 기본적인 API에서는 해당 API를 사용하는 클라이언트가 API의 URL 스키마를 알고 있어야 했다.
•
API 클라이언트 코드에는 흔히 하드코딩된 URL 패턴을 사용하고 문자열로 처리한다. 그러나 API의 URL 스키마가 변경된다면 어떻게 될까?
•
따라서 API URL을 하드코딩하고 문자열로 처리하면 클라이언트가 의존성을 많이 가지게 되어 결합도가 증가하는 단점을 낳는다.
•
REST API를 구현하는 또 다른 방법으로 HATEOAS가 있다. 이는 API로부터 반환되는 리소스에 해당 리소스와 관련된 하이퍼링크들이 포함된다.
◦
따라서 클라이언트가 최소한의 API URL만 알면 반환된느 리소스와 관련하여 처리 가능한 다른 API URL들을 알아내어 처리할 수 있다.
◦
/users를 조회했을때, 세부 자원인 user를 조회하고 싶다면 해당 URL을 반환하는 식의 처리다.
3. 데이터 기반 서비스 활성화하기
•
스프링 데이터는 우리가 코드에 정의한 인터페이스를 기반으로 레포지터리 구현체를 자동으로 생성하여 필요한 기능을 수행한다.
◦
외에도 스프링 데이터는 어플리케이션의 API를 정의하는 데 도움을 줄 수도 있는 기능이 존재한다고 하는데.. 표현 계층에 과하게 접근하는 것 같아 별로다.
◦
물론 간단한 프로젝트라면 사용해도 좋을 것 같긴 하다.
요약
•
REST 엔드포인트는 스프링 MVC, 그리고 브라우저 지향의 컨트롤러와 동일한 프로그래밍 모델을 따르는 컨트롤러로 생성할 수 있다.
•
모델과 뷰를 거치지 않고 요청 응답 몸체에 직접 데이터를 쓰기 위해 컨트롤러의 핸들러 메소드엔 @ResponseBody 어노테이션을 지정할 수 있으며 ResponseEntity 객체를 반환해도 된다.
•
@RestController 어노테이션을 컨트롤러에 지정하는 경우 해당 컨트롤러의 각 핸들러 메소드에 @ResponseBody를 지정하지 않아도 되므로 컨트롤러를 단순화 해준다.
•
스프링 HATEOAS는 스프링 MVC에서 반환되는 리소스에 하이퍼링크를 추가해줄 수 있게 한다.
•
스프링 데이터 레포지터리는 스프링 데이터 REST를 사용하는 REST API로 하여금 노출시킬 수 있다.
