look-forest

# 테스트할 것JSON 응답이 201로 나오는지입력 값 제한 # 구현 코드 API 응답 컨트롤러@RestController@ResponseBody를 모든 메소드에 적용한 것과 동일하다ResponseEntity를 사용하는 이유응답 코드, 헤더, 본문 모두 다루기 편한 API객체를 JSON으로 변환ObjectMapper 사용DTO를 Entity로 변환ModelMapper 사용 (Bean으로 등록해야 함)@Configurationpublic class AppConfig { @Bean public ModelMapper modelMapper() { return new ModelMapper(); } 입출력 값 제한입력값 제한 - DTO와 ModelMapper 활용id 또는 입력 받은 데..

검증 기능을 매번 코드로 작성하는 것은 상당히 번거롭다.특히 특정 필드에 대한 검증 로직은 대부분 빈 값인 지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다즉, 정형화 할 수 있다.이런 검증 로직을 애노테이션을 활용해 모든 프로젝트에 적용할 수 있게 공통화, 표준화 한 것이 바로 Bean Validation이다.※ 여기서 말하는 Bean은 Spring Bean이 아니라 Java Bean이다. (캡슐화를 통해 데이터와 메소드를 하나의 객체로 묶는 형태. 주로 getter/setter를 통해 필드 접근)Bean Validation 적용spring-boot-starter-validation 의존관계를 추가하면 Bean validation을 사용할 수 있다. 기존에 만든 validator는 ..

고객이 입력한 값을 검증할 필요가 있다.클라이언트 검증은 조작할 수 있으므로 보안에 취약하다 (postman만 써봐도 우회가 가능)서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다.=> 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수 먼저 검증을 직접 구현해보고, 뒤에서 스프링과 타임리프가 제공하는 검증 기능을 활용해보자 version1. 순수 검증 직접 구현 검증 로직 에러 메시지를 모델에 담아 뷰로 보내고, 뷰에서 처리한다. 화면 처리 화면 처리 시 고객이 이전에 입력한 데이터가 보이는 이유는, 애초에 객체를 보내도록 설계했기 때문이다.  문제는 중복이 너무 많고, 번거롭다는 것과타입 검증이 불가하다는 것이다. 타입 오류는 컨트롤러에 오기 전에 바인딩 오류가 발생해서 400에러가 발생..