Controller
public @ResponseBody
ResponseEntity<UserResponse> getUserInfo(@Login User loggedInUser) {
UserResponse user = userService.getUserInfo(loggedInUser);
return new ResponseEntity<>(user, HttpStatus.OK);
}
Service
@Override
public UserResponse getUserInfo(User loggedInUser) {
User userInDB = userMapper.getUserById(loggedInUser.getId().longValue());
return UserConverter.INSTANCE.toUserResponse(userInDB);
}
클래스 혹은 메서드에 @Auth애너테이션이 붙은 컨트롤러의 메서드에, (JWT 검증이 이루어지는 API 엔드포인트)
@Login User user와 같은 형식을 작성한다면
의 효과를 얻을 수 있다.
기존 로직의 좋지않은 계층간 참조 (Service Layer에서 Presentation Layer의 계층을 참조)
HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest() 을 이용하여 Jwt 토큰을 획득하여 검증함.=> Service 계층에서 서블릿, 헤더 자체를 호출하지 않도록 수정해야 했음.
컨트롤러이지만, 도메인(User.java)를 사용하였다.
컨트롤러에서 DTO를 사용하는 이유는 API의 RequestBody로 들어오는 객체와 서비스 객체의 의존성을 분리하기 위함이라고 생각하는데, 사용자 정보의 경우 이미 검증 로직에 도메인으로 활용하기에 의존성을 줄이는 것이 의미가 없을거라 생각했다.
또한, 리졸버에서 UserDomain -> UserRequestDTO 로 변환 후 추후 다시 UserDomain을 변환하는 불필요한 반복작업이 생길 것이고, 도메인을 RequestDTO로 변환한다는 흐름도 흐름과 맞지않다 생각하였다.
인터셉터에서 사용자 아이디 뿐만이 아니라, DB의 사용자 자체를 사용하기에 (1. 탈퇴여부 확인 2. 여러 권한 검증) 리졸버의 역할이 크지 않게 되었다.