ResponseEntity

📌 개요

본 내용은 내가 그동안 구현한 API들이 잘 구동이 되는지 확인차, 백엔드 자체 테스트를 하다가 발견하여 개선한 내용 중 하나이다.

위 사진에 나온것 처럼, 에러가 났을 경우( ex. 중복에러), 해당 에러 메세지의 경우 httpStatus는 내가 지정해준 409 코드를 내보내지만, 정작 status code는 200 코드가 찍히는 것을 발견했다.
사실 나는 httpStatus로 에러 코드를 내보냈고, 프론트쪽에서 알림창을 내보내고 있기 때문에 status code가 200으로 나가고 있다는 사실을 모르고 있었다. status code가 내가 보낸 httpStatus에 맞게 변경되도록 개선한 바를 간단히 말하고 그 속의 개념들을 정리하려고 한다.

🌱 기존에는 어떻게 되어 있었나?

기존의 코드의 경우 성공과 실패 모두에 대한 응답 데이터를 담는 클래스인 ApiResponseEnvelop으로 응답하도록 되어있다. (진짜 혹시나 spring에서 제공해주는 클래스라고 오해할 수 있어서 말하는 것인데, ApiResponseEnvelop은 내가 만들어준 클래스다. )
ApiResponseEnvelop을 통해 응답하게 되면, 모든 응답에 대해 일관성 있는 구조를 유지할 수 있고, 필요한 데이터 타입을 포함하여 다양한 유형의 응답을 생성할 수 있다.

즉, 내가 내보내고 싶은 데이터들이 모든 api의 응답에 있어서 일관되게 나가서, 성공 또는 실패와 관계없이 응답은 항상 특정 형태로 반환되므로 클라이언트 측에서 응답을 다루기 쉽다.
그래서, ApiResponseEnvelop의 장점을 살리면서도 status code를 개선하고 싶었다.

📌 ResponseEntity

위에서 언급한 바의 해결 방법이 바로 ResponseEntity를 활용하는 방법이다.

ResponseEntity 코드를 보면, ResponseEntity는 HttpEntity 를 상속한 클래스로, Status 만 필드 값으로 가지고 있다는 것을 알 수 있다. 상속된 httpEntity의 내부를 가볍게 봐보자.

httpEntity 필드 타입으로 HttpHeaders 를 가지고 있어서 Header 를 설정해 줄 수 있다는 것을 알 수 있다. 즉, httpEntity를 상속한 ResponseEntity에서 직접적으로 Status Code 를 지정할 수 있다는 것을 의미한다.

문서에서도 전체 HTTP 응답(상태 코드, 헤더 및 본문)을 나타낸다고 써져있다.

📌 적용

따라서, 에러가 났을 경우, ResponseEntity가 기존의 custom 응답 객체를 감싸서 응답하도록 적용하였다. 그 결과 처음에 status code가 불일치한 현상이 해결되었다.

📌 소감

이번에 해결도 해결이지만 가장 크게 느낀 것은, 프론트 쪽과 원활한 소통의 중요성이었다. 이번 일이 프론트 코드에 많은 영향을 끼칠 수 있다는 점을 간과하여 미리 협의하지 않고 배포해 버렸다는 점이 개인적으로 많이 아쉬웠다. 이번 경험을 바탕으로 의사소통이 원활한 개발자가 되어야 한다는 인식을 다시 한번 마음속으로 새기게 되었다.