Spring의 Response Entity 꼭 사용해야 하는가?

개요

새로운 사이드 프로젝트를 시작하면서 여러 고민을 하게 되었다, 바로 전의 사이드 프로젝트인 슬축생은 공부가 목적이 아닌 필요로 의해서 개발된 프로젝트기 때문에 최대한 비즈니스 요구사항에 맞추며 배포까지 시간이 많이 없었기에 개발쪽 리소스를 줄여서 개발을 하였다.

 

하지만 이번에 하는 사이드 프로젝트는 비즈니스적인 부분도 꽤 크고 복잡할뿐더러 공부의 목적도 함께 있는 프로젝트이기 때문에 정말 작은 부분에서도 신경을 많이 쓰게 되었다.

 

정말 많은 고민중에 가장 첫번째로 결정한 주제가 바로 Response Entity의 필요성이다. Response Entity의 존재에 대해서는 예전부터 알고 있었다.

 

본격적으로 공부하기전에 알던 사전 지식으로는 http 상태 코드 및 헤더 등 여러 상세한 부분을 설정할 수 있지만 그로 인하여 코드가 몇줄 늘어난다는 단점이 있다고 알고 있었다. 이번 기회에 제대로 파악해보고 어떤면에서 필요성이 있는지 알아보자.

Response Entity란 무엇인가?

공식 문서에 따르면 Response Entity란 http 상태 코드를 설정하는 기능을 추가한 Http Entity의 확장 클래스라고 한다. RestTemplate과 Controller 어노테이션에서 주로 사용된다고 한다.

위와 같이 사용할 수 있다, 제네릭 선택지가 있는데 제네릭에는 body의 타입을 넣어주면 된다.

아마 이번 프로젝트에 도입한다면 저번 프로젝트에 사용했던 응답 DTO를 넣어서 사용하지 않을까 싶다.

 

Status로 Http Status를 설정할 수 있고 header를 통해서 다양한 헤더들을 작성할 수 있다.

Response Entity를 꼭 사용해야 하는가?

근거들을 가지고 오기 전, 나의 개인적인 생각은 이것도 결국 Trade-Off 라고 생각을 했다.

 

도메인이 복잡하고 클라이언트에서 헤더들의 정보를 많이 참고하고 이용하거나 HTTP 상태 코드로 예외처리 및 분기처리를 하는 서비스라면 당연히 사용해야한다. 하지만 정말 간단하고 단순한 도메인의 프로젝트에서는 @RestController 어노테이션만으로 충분하다고 생각했다.

 

하지만 국내,외 글들을 참고하여 Response Entity의 필요성에 대해서 공부하고 결국 처음에 생각했던 이유들과 비슷했다.

 

이 글을 여러가지의 근거를 제시하며 길게 작성할 줄 알았으나 생각보다 결론은 간단했다.

 

클라이언트와 소통하기 좋은 RestAPI 설계를 위해선 Http 상태코드와 헤더들을 적극적으로 활용해야한다, 그리고 이런 부분을 도와주는것이 Response Entity인것이다.

마무리하며

Response Entity를 사용할지 말지 생각해보기전에 좋은 RestAPI의 응답 예제들부터 접해보고 공부해보자 라는 생각이 들었다. 사실 지금까지 한번도 응답에 헤더를 사용한적이 없었다. 하지만 분명 많은 프로덕트들이 적극적으로 헤더와 상태 코드를 활용하고 있는것이 분명하고 어떠한 목적으로 사용하는지 공부해봐야겠다는 생각이 들었다.