기존 코드
기존에 상태코드와 메시지를 포함해서 전달해달라는 요청을 받고 위처럼 바로body에 String으로 담아서 전달했다.
이걸 보고 한 팀원께서 리뷰를 해주셨는데, ResponseEntity에 ApiResponseDto를 담아서 전달하는 형태로 통일하자고 했다.
수정된 코드
ResponseEntity타입으로 반환을 명시했고, 지네릭스로 미리 만들어둔 ApiResponse를 담기로 선언했다.
ApiResponse 클래스는 위와 같이 상태코드와 상태메시지를 담는 형태이고,
@ToString을 붙여줘 자동으로 해당 객체를 반환해도 필드명을 포함해서 전달하도록 했다. (팀원으로부터 처음 알게 된 기능)
해당 api의 성공과 실패시의 return을 각각 위와 같이 작성했다.
ApiResponseDto의 생성자의 첫 파라미터에는 메시지를, 두번째에는 상태코드이다.
각 서비스마다 상태코드를 직접 상수로 커스텀하기도 하지만, 우선은 HttpStatus에서 적용되는 값을 그대로 가져왔다.
ResponseEntity를 사용하면 좋은 이유
팀원이 튜터님께 이렇게 하는 게 좋다고 해서 바꾸긴 했지만 왜인지 더 궁금하다.
Restful API를 위해, Http규격을 위해
흔히 Restful하게 개발을 한다는 데, 그 중에 한가지 큰 의미는 여러 플랫폼에서도 잘 동작하게끔 하는 것이다.
이전에는 웹을 대상으로만 개발이 됐지만 요즘은 핸드폰부터 TV, 각종 Iot까지 많은 플랫폼으로 개발이 되어야한다.
이 때 각자 개발해둔 방법으로 JSON데이터를 보내는 경우가 발생할 수 있는데, 이와 같은 일들이 발생하고 쌓이면 모든 방법에 대응할 수 있는 방어코드를 만들어야 하고 이는 속도 저하로 이어진다고 한다.
이에 Http규격을 지키며 응답의 형태를 가져가는 것이 궁극적으로 좋다.
ref
https://dev-splin.github.io/spring/Spring-ResponseEntity/
'Back-End > Spring' 카테고리의 다른 글
TIL 230726 : CustomException 사용하기 (0) | 2023.07.26 |
---|---|
TIL 230725 : RestControllerAdvice로 전역 예외 처리 (0) | 2023.07.25 |
TIL 230703 : JPA Buddy라는 것이 이 세상에 있었다 (0) | 2023.07.03 |
TIL 230630 : (이어서) Entity반환시 문제. (Dto의 중요성) (0) | 2023.06.30 |
TIL 230629 : List to JSON 객체 반환시 오류 (jackson) (0) | 2023.06.29 |