[TIL] #38. Validation

---

 

 [ Validation ] 

: HTTP 요청이 정상인지 검증

Front 검증

- 유저가 조작할 수 있기 때문에 보안에 취약
- 그럼에도 필요하다

 

Server 검증

- front 없이 서버에서만 검증 = 유저 사용성이 떨어짐.
- API Spec을 정의해서 validation 오류를 response 예시에 남겨줘야 한다.
- 서버 검증은 필수

 

Database 검증

- Default, Not Null ,,,

 

---

 

 [ BindingResult ] 

: validation 오류를 보관하는 객체
  @ModelAttribute를 이용해 매개변수를 바인딩할 때 발생한 오류를 보관하는 객체이다.

- BindingResult 파라미터는 @ModelAttribute 파라미터 뒤에 와야 한다. 

 

---

 

 [ Bean Validation ] 

: 기술 표준 인터페이스
   - 다양한 validation annotation들과 여러가지 interface로 구성되어있다.
   - JPA의 구현체로 하이버네이트가 존재하고, 대부분 Bean Validation 구현체인 하이버네이트 Validator를 사용한다. 

- BindingResult, FieldError, ObjectError를 통해 Controller에서 값을 검증할 수 있지만, 이 경우 Controller의 크기가 너무 커지고 단일 책임 원칙에 위배된다.

 

사용

@NotBlack
  - null을 허용하지 않음
  - 공백(" ")을 허용하지 않음 (하나 이상의 문자를 포함해야 한다)
  - 빈값("")을 허용하지 않음
  - CharSequence 타입을 허용함

@NotNull
  - null을 허용하지 않음
  - 모든 타입을 허용함

@NotEmpty
  - null을 허용하지 않음
  - 빈값("")을 허용하지 않음
  - CharSequence, Collection, Map, Array 타입을 허용함

 

동작 순서

1. @ModelAttribute 각각의 필드 타입에 맞춰 바인딩 시도
  - 성공 > 다음 동작
  - 실패 > typeMismatch FiledError 발생

2. validation 적용
  - @ModelAttribute > 각 필드 바인딩 > 성공한 필드만 Bean Validation 적용
  - Bean Validator는 바인딩에 실패한 필드를 적용하지 않는다
  - 타입 바인딩에 성공한 필드만 Bean Validation을 적용하는 의미가 있다 (Integer 타입 필드에 문자가 오면 애초에 검증의 의미 없음)
  - 성공 예시) String 필드에 문자 입력 > 바인딩 성공 > String 필드에 Bean Validation 적용
  - 실패 예시) Integer 필드에 문자 입력 > 바인딩 실패 > typeMismatch FiledError 추가 > 바인딩에 실패한 필드는 null임 > Bean Validation 적용하지 않음