뭐? RestTemplate이 Deprecate 된다고?

doxxx·2023년 8월 9일

RestTemplate Spring Springboot webclient

Spring Framework

목록 보기

2/3

RestClient

~~교묘하게 Tag에 RestClient를 숨겼다.~~

개요

RestClient는 Spring 6.1 에 등장하는 HttpClient이다.

Spring WebFlux의 WebClient는 Spring 5.0에 소개된 비동기, 리액티브 HttpClient인데, 이는 기존의 3.0에서 소개된 RestTemplate를 대신해왔다.

물론 WebClient는 동기 요청에 대해서도 block()메서드를 이용하여 아주 잘 처리할 수 있었다.

그렇다면 이미 잘 되어있는데 RestClient를 왜 도입하게 되는걸까?

등장 배경

선 요약하자면, 2가지 이유이다.

RestTemplate가 너무 오래 됐다.
WebClient는 spring-boot-starter-webflux dependency가 필요하다.

레스틀템플릿

스프링 3.0에 소개된 RestTemplate은 버젼이 단 3개 차이지만 2009년에 발표되어 햇수로 따지면 14년 전이다.

잘만 만들었으면 됐지 오래된게 뭐가 문제냐 싶을 수 있지만, 스프링의 입장은 Template(과 같은) 클래스가 HTTP의 기능들(capability)을 노출하게 됨에 따라, 너무나 많은 메서드들을 오버로드하는 결과를 초래한다는 것이다.

고수분들이라면, 이러한 문제가 어떤 문제점들을 초래하는지 아실테지만

복잡성과 유지보수의 어려움: RestTemplate이 다양한 메서드를 제공하면서 많은 옵션을 다루게 되면, 이를 사용하는 코드가 복잡해질 수 있습니다. 여러 메서드의 조합이 필요하거나 다양한 설정을 고려해야 할 때 코드의 가독성과 유지보수성이 저하될 수 있습니다.
API 변경의 어려움: RestTemplate 클래스가 많은 메서드를 포함하고 있다면, 이후에 API의 변화나 업데이트에 대응하기 어려울 수 있습니다. 새로운 HTTP 기능이나 설정이 추가되거나 기존 메서드의 동작이 변경될 때, 이에 대한 대응이 복잡하고 오류가 발생할 가능성이 있습니다.
불필요한 의존성: 다양한 기능을 모두 하나의 클래스에 포함하면, 사용하지 않는 기능에 대한 의존성도 함께 추가됩니다. 이는 불필요한 라이브러리 및 코드를 포함하게 되어 프로젝트의 용량을 증가시키고, 애플리케이션의 성능에 영향을 미칠 수 있습니다.
테스트의 어려움: 많은 메서드와 옵션을 다루어야 할 때, 각각의 케이스에 대한 테스트 작성이 복잡해질 수 있습니다. 특히 다양한 조합의 경우를 모두 커버하기 어려울 수 있습니다.

위와 같은 문제점이 있을 수 있다고 GPT형님이 알려주셨습니다.

WebClient

필자의 경험이다.

Spring MVC 프로젝트이지만, 외부 API 요청을 위해 WebClient를 썼었다. 진짜 열받게도 이거 하나 쓰려고 build.gradle에

implementation 'org.springframework.boot:spring-boot-starter-webflux'를 추가해야했다.

RestTemplate, FeignClient도 고려를 했지만 (사실무근인) RestTemplate이 deprecate 된다는 인터넷들의 글을 읽게된 점, 그리고 FeignClient를 쓰기 위해 build.gradle에 Spring Cloud 관련 dependency를 추가해야되는 점등을 겪고서는 홀라당 WebClient를 쓰게 되었다.

사실 결정타를 날린건 Spring Reference이다. 대놓고 RestTemplate은 유지보수 모드라서 WebClient를 쓰라고 적어뒀다.