Multipart/form-data와 Validation의 관계

배경

어느 API에서 파일과 DTO를 같이 받기 위해 Multipart/form-data 라는 content-type을 사용했었습니다.

"file": 파일의 blob
"json": stringfy된 json
Plain Text
복사

form-data엔 위 방식대로 받고 있었고 각 key-value쌍의 파트로 구분되었습니다.

클라이언트측에는 json 파트의 content-type을 application/json으로 따로 지정해서 요청해달라고 하였지만

이를 이용하는데 어려움이 있어서 다른 방법을 찾게 되었습니다.

여기서 선택지는 2가지였습니다.

json의 각 필드를 백엔드측에서 Map으로 받는 방법

text/plain 타입으로 받은 뒤 ObjectMapper나 Gson을 사용해 DTO로 매핑하는 방법

1번의 경우는 필드가 많아지고 value의 타입이 다양해지면 Map<String, Object>로 받아야해서 꺼내는 과정에서 굉장한 번거로움과 타입에러가 발생할 것 같다고 생각했습니다.

그래서 2번을 사용하기로 결정한 이야기입니다..

사건의 등장

@PutMapping(value = "/{companyId}", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ResponseEntity<ResponseDTO> updateCompany(HttpServletRequest request,
                                                 @RequestPart(required = false) MultipartFile logo,
                                                 @Parameter(schema = @Schema(implementation = CompanyUpdateDTOforBiz.class)) @RequestPart String json,
                                                 @PathVariable Long companyId) throws IOException {
    CompanyUpdateDTOforBiz dto = objectMapper.readValue(json, CompanyUpdateDTOforBiz.class);
    return new ResponseEntity<>(companyService.updateCompany(request, dto, logo, companyId), HttpStatus.OK);
}
Java
복사

Controller의 코드는 위와 같았고 json을 DTO가 아닌 String으로 받도록 변경하였습니다.

ObjectMapper를 이용하여 DTO로 매핑하는데까진 문제가 없었지만 테스트를 돌리자 사건이 발생했습니다.

실패하는 조건의 테스트만 모조리 실패하는 것을 보니 Validation이 제대로 작동하지 않고 있는 것을 알아차렸습니다.

여기서 잠깐 스프링의 WebDataBind 과정을 살펴보고 가겠습니다.

이 사진은 Spring MVC 구조에서 HTTP 요청에서부터 컨트롤러까지를 크게 보여주는 사진입니다.

HTTP 요청이 들어오면 DispatcherServlet은 핸들러 매핑에게 어떤 컨트롤러가 처리할지 찾으라고 시킵니다.

핸들러 매핑은 DispatcherServlet에게 적당한 컨트롤러를 찾아서 알려주고 핸들러 어댑터에게 그 컨트롤러를 찾아서 요청을 처리하라고 전달합니다.

이제 컨트롤러는 사진엔 표시되지 않은 Service 레이어와 Repository 레이어를 거쳐 데이터를 반환합니다.

이제 핸들러 어댑터가 어떠한 일을 하는지 더 자세하게 살펴보겠습니다.

저희는 Controller 레이어에 메서드를 작성할 때 HttpServletRequest, @RequestBody, @RequestParam, @ModelAttribute 등 많은 종류의 파라미터와 어노테이션을 사용합니다.

DispatcherServlet에게 특정 컨트롤러를 통해 HTTP 요청을 처리하라고 전달 받은 핸들러 어댑터는 여러 파라미터와 어노테이션 정보를 기반으로 컨트롤러에 전달할 데이터를 생성합니다.

이 때 많은 종류의 파라미터를 처리해주는 것은 바로 ArgumentResolver입니다.

ArgumentResolver는 저희가 @RequestBody 어노테이션을 붙여 DTO로 받고 싶어하는 파라미터에 대한 매핑을 HttpMessageConverter를 통해서 처리합니다.

ArgumentResolver 뿐만 아니라 HttpMessageConverter 또한 인터페이스로 여러 개의 구현체를 갖고 있습니다.

저의 상황에선 DTO로 받을 때 HttpMessageConverter의 구현체 중 Jackson2HttpMessageConverter를 사용하던 것을 String으로 받는 방식으로 변경하면서 StringHttpMessageConverter를 사용하게되었습니다.

이제 제가 작성한 DTO를 살펴보겠습니다.

@Getter @Setter
@NoArgsConstructor
public class CompanyUpdateDTOforBiz {
    @NotNull(message = "직원 수가 입력되지 않았습니다.", groups = ValidationGroups.NullCheckGroup.class)
    @Min(value = 1, message = "직원 수는 최소 1명 이상이어야합니다.")
    @Schema(name = "employee_number", description = "직원 수", example = "100", required = true)
    @SerializedName("employee_number")
    private Integer employeeNumber;

    @NotBlank(message = "주소가 공백이거나 입력되지 않았습니다.")
    @Schema(description = "주소", example = "서울 강남구 테헤란로 217", required = true)
    private String address;

    @NotBlank(message = "한 줄 소개가 공백이거나 입력되지 않았습니다.", groups = ValidationGroups.NullCheckGroup.class)
    @Length(max = 120, message = "한 줄 소개가 120자를 초과하였습니다.")
    @Schema(description = "한 줄 소개", example = "생산/전문직 전용 채용 플랫폼", required = true)
    private String intro;

		...
}
Java
복사

제가 작성한 DTO는 위와 같이 validation group을 사용하고 있었기 때문에 @Valid 대신 @Validated를 사용해야했습니다.

@Validated는 javax 라이브러리가 아닌 스프링 프레임워크에서 제공하는 어노테이션으로 ArgumentResolver를 통해 구현되는 로직이 아닌 AOP를 통해서 동작하는 방식입니다.

사실 @Valid를 사용하든 @Validated를 사용하든 제가 받는 json은 String 타입이기 때문에 validation이 제대로 작동하지 않았을 것입니다.

해결한 방법

이미 String으로 받기 시작한 이상 Controller 레이어 이후에서 Validation 과정을 직접 하기로 하였습니다.

우선 String에서 DTO로 매핑하는 과정을 프로젝트에선 Gson과 ObjectMapper 두 가지를 모두 사용하고 있어서 MapperConfig 클래스를 만들어 각각에 대한 설정을 해주기 위해 빈으로 등록해줍니다.

@Configuration
public class MapperConfig {
    @Bean
    public ObjectMapper objectMapper() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.registerModule(new JavaTimeModule());
        objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
        objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
        objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
        return objectMapper;
    }

    @Bean
    public Gson gson() {
        return new GsonBuilder()
                .registerTypeAdapter(LocalDate.class, new LocalDateSerializer())
                .registerTypeAdapter(LocalDate.class, new LocalDateDeserializer())
                .registerTypeAdapter(LocalDateTime.class, new LocalDateTimeSerializer())
                .registerTypeAdapter(LocalDateTime.class, new LocalDateTimeDeserializer())
                .create();
    }

    public static class LocalDateSerializer implements JsonSerializer<LocalDate> {
        @Override
        public JsonElement serialize(LocalDate src, Type typeOfSrc, JsonSerializationContext context) {
            return new JsonPrimitive(src.format(DateTimeFormatter.ofPattern("yyyy-MM-dd")));
        }
    }

    public static class LocalDateDeserializer implements JsonDeserializer<LocalDate> {
        @Override
        public LocalDate deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException {
            return LocalDate.parse(json.getAsString(), DateTimeFormatter.ofPattern("yyyy-MM-dd"));
        }
    }

    public static class LocalDateTimeSerializer implements JsonSerializer<LocalDateTime> {
        @Override
        public JsonElement serialize(LocalDateTime src, Type typeOfSrc, JsonSerializationContext context) {
            return new JsonPrimitive(src.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss")));
        }
    }

    public static class LocalDateTimeDeserializer implements JsonDeserializer<LocalDateTime> {
        @Override
        public LocalDateTime deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException {
            return LocalDateTime.parse(json.getAsString(), DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss"));
        }
    }
}
Java
복사

위 코드에서 먼저 ObjectMapper를 보면 날짜/시간에 대한 모듈을 추가해줘 직렬화/역직렬화 과정에서 에러가 발생하지 않게 해줍니다.

또한 PropertyNamingStrategy를 지정해주어 개발팀 내에서 약속한 규칙인 SNAKE_CASE로 설정해줍니다.

마지막으로 @JsonIgnore가 붙은 프로퍼티를 무시하기 위한 설정까지 해줍니다.

그 아래부터는 Gson에 대해 직렬화/역직렬화 과정 중 날짜/시간에 대한 포맷 설정을 해주는 코드입니다.

매퍼들에 대한 설정이 끝났으니 이제 Controller를 살펴보겠습니다.

@PutMapping(value = "/{companyId}", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ResponseEntity<ResponseDTO> updateCompany(HttpServletRequest request,
                                                 @RequestPart(required = false) MultipartFile logo,
                                                 @Parameter(schema = @Schema(implementation = CompanyUpdateDTOforBiz.class)) @RequestPart String json,
                                                 @PathVariable Long companyId) throws IOException {
    CompanyUpdateDTOforBiz dto = objectMapper.readValue(json, CompanyUpdateDTOforBiz.class);

    Validator validator = validatorFactory.getValidator();
    Set<ConstraintViolation<CompanyUpdateDTOforBiz>> constraints = validator.validate(dto);

    if (!constraints.isEmpty()) {
        String message = constraints.stream().map(ConstraintViolation::getMessage).findFirst().get();
        throw new CustomException(Arrays.stream(ErrorCode.values()).filter(e -> e.getErrorMessage().equals(message)).findFirst().get());
    }

    return new ResponseEntity<>(companyService.updateCompany(request, dto, logo, companyId), HttpStatus.OK);
}
Java
복사

먼저 objectMapper를 DI 받아서 String으로 받아온 json을 DTO로 매핑해줍니다.

그 다음부턴 Validation을 직접 해주는 과정으로 저를 괴롭혔던 문제를 해결한 방법입니다.

ValidatorFactory를 DI 받아서 factory로부터 validator를 가져온 후 validate() 메서드를 이용해 검증 과정을 거쳐줍니다.

검증 과정의 결과물로 Set<ConstraintViolation<DTO>> 를 받는데 이 안에는 검증에서 발생한 Validation 에러들이 들어있습니다.

이 이후부터는 개인의 취향에 따라 처리하기 나름이라고 생각합니다.

@Getter
@AllArgsConstructor
public enum ErrorCode {
    BLANK_MEMBER(404, "BLANK_MEMBER", "해당 유저가 존재하지 않습니다.", HttpStatus.NOT_FOUND.name()),
    WRONG_EMAIL(400, "WRONG_EMAIL", "올바른 이메일 형식을 입력해주세요.", HttpStatus.BAD_REQUEST.name()),
    BLANK_EMAIL(400, "BLANK_EMAIL", "이메일이 공백이거나 입력되지 않았습니다.", HttpStatus.BAD_REQUEST.name()),
    DUPLICATED_EMAIL(400, "DUPLICATED_EMAIL", "이미 가입된 이메일 입니다.", HttpStatus.BAD_REQUEST.name()),
	
		...		

    private final int status;
    private final String errorCode;
    private final String errorMessage;
    private final String statusName;
}
Java
복사

저의 경우에는 모든 에러코드에 대해서 Enum 클래스 하나로 관리하고 있기 때문에

만약 검증과정에서 에러가 존재한다면 해당 에러코드를 찾아 Exception을 터트려 주는 방식으로 처리하였습니다.

@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(CustomException.class)
    protected ResponseEntity<ErrorResponseDTO> handleCustomException(CustomException e, HttpServletRequest request) {
        ErrorResponseDTO error = ErrorResponseDTO.builder()
                .status(e.getErrorCode().getStatus())
                .errorMessage(e.getErrorCode().getErrorMessage())
                .errorCode(e.getErrorCode().getErrorCode())
                .statusName(e.getErrorCode().getStatusName())
                .path(request.getRequestURI())
                .build();

        return new ResponseEntity<>(error, HttpStatus.valueOf(e.getErrorCode().getStatus()));
    }
}
Java
복사

CustomException(ErrorCode errorCode) 로 예외가 발생하면 미리 설정해준 ExceptionHandler가 ErrorResponse를 만들어 응답해줍니다.

이렇게해서 Multipart/form-data 를 사용하며 클라이언트의 요청에 따라 json을 건낼 때의 타입을 변경할 수 있었습니다.

또한 의도치않게 그 동안 Swagger에선 application/octet-stream으로 설정돼서 정상적인 요청이 안되던 것도 해결되었습니다.