아이디어라기 보다, 이전 코드들을 살펴보다가 발견해서 공유합니다
저는 지금까지는 컨트롤러에서 dto를 통해 어떠한 값을 받을 때 @RequestBody와 @RequestPart만 사용해서 값을 받았습니다. 아마 팀원 분들도 저와 같았을 것이라고 생각합니다. @RequestBody를 Dto앞에 붙여서 json을 자바 객체로 역직렬화하여 값을 꺼내서 받아고 @RequestPart는 Mutipartfile을 처리하기위해 사용했습니다. 지금까지 문제가 없었고 잘 되어왔습니다.
최근 Spring mvc로 업무를 보고 학습하던 중 Spring mvc 와 Restapi 개발에 있어 상황에 따라 항상 헷갈려했습니다.
DTO에 대한 검증에는 @Validated 애노테이션과 @Valid 애노테이션이 있습니다. 찾아보니, @Validated 애노테이션은 스프링에서 만든 것이고 @Valid는 자바가 만든 것인데, @Validated가 기능이 더 많아서 이를 더 많이 사용한다고 합니다.
하지만 여기서 의문이 생겼습니다. 과연 이 유용한 애노테이션들이 mvc패턴에만 쓰이고 RestApi 설계에서는 사용하지 안할까? 너무 아깝지는 않나?
하고 알아본 결과 RestApi에서도 아주 유용하게 쓰인다고 합니다. DTO를 매개변수로 받는 단에서 @Validated를 사용하여 검증을 한다는 것을 알리고, 검증을 하다 이 오류 메시지를 바로 뒤인 BindingResult에 담아서 보내줍니다.
그럼 이 과정이 도대체 왜 필요하냐?
1.
만약 클라이언트와 대화가 안되는 곳에서 개발을 해야한다고 가정을 해봅시다. 그러면 우리는 명세서에 적어줄 것이고 그것을 클라이언트가 보고 개발을 하겠죠. 하지만 명세서가 없다거나 명세서를 잘못 작성했다면? 예를 들어 어떠한 객체 필드 명이 isPrivate 인데 arePrivate로 명세서로 작성을 했다면? 타입이 잘못됐다면?
2.
클라이어트가 바뀌어 기존 내용을 잘 모르던 클라이언트와 협업을 하게 됐을 때 자주 일어나는 경우
이럴 때 검증이 필요합니다.
우리는 항상 예외처리만을 해왔는데, DTO에 대한 검증은 안하고 있었습니다. 사실상 클라이언트를 신뢰한다는 사실 기반으로 개발을 해왔습니다. 하지만 만약 다른 회사 클라이언트와 협업을 한다면 DTO에 대한 이러한 검증들을 일일히 하나씩 다른 방법이 아닌 ‘코드’로 왜 틀렸는지에 대해 알려줘야합니다.
사용 예시
이러한 방법으로 검증을 해야합니다. 하지만 저렇게 된다면 에러가 존재하는지 확인하고 예외처리만 내려주겠죠.
기존에 있던 예외처리들을 유지하며 새로운 ObjectError를 넘길 수 있는 예외를 만들고, Exception enum 클래스에서 수정을 하고 나면, ObjectError를 오류 메시지로 담고, 상태코드는 새로 생성해서 보낼 수 있습니다. 이를 컨트롤러 단에서 만들면 좋을 것 같습니다.
ObjectError이기 때문에 RestControllerAdvice를 사용하지 않고 검증 오류를 때에 따라 만들어 줄 수 있게 직접 생성하는 편이 좋을 것 같습니다.
어려분들 의견이 궁금합니다.