🌈 [Section3] 2. [ Spring MVC ] API 계층 2

📕 오늘 배운 내용!

• DTO 클래스
• 유효성 검사

---

✏️ DTO (Data Transfer Object)

• 데이터 전송을 위한 용도의 객체
  ( 요청 데이터와 응답 데이터에서 사용 )
  
  

➜ 주로 클라이언트에서 서버 쪽으로 전송하는 요청 데이터를 전달 받을 때, 서버에서 클라이언트 쪽으로 전송하는 응답 데이터를 전송하기 위한 용도

✔️ Request Body
➜ 요청 데이터 중 body에 해당되는 데이터
( 여기서 말하는 요청 데이터들은 모두 Request Body를 말하는 것 )

 

✔ DTO가 필요한 이유

• 클라이언트의 Request Body를 하나의 객체로 모두 전달 받을 수 있기때문에 코드 자체가 간결
• Request Body의 데이터 유효성(Validation) 검증이 단순해짐

💡 원래 실습 내용에서 Map으로 요청데이터를 받았었는데
이 경우 데이터를 하나하나 받을 때 마다 @RequestParam 애너테이션을 써줘야함
➜ 데이터가 많아질 수록 불편
⠀⠀
따라서 DTO 클래스를 이용하여 DTO 클래스에 요청데이터를 받고,
그 DTO 클래스를 ResponseEntity 객체의 생성자 파라미터로 넘겨주면 코드가 훨씬 간결해짐

✔️ ResponseEntity
- HttpEntity의 확장 클래스로써 HttpStatus 상태 코드를 추가한 전체 HTTP 응답(상태 코드, 헤더 및 본문)을 표현하는 클래스

[참고] https://itvillage.tistory.com/44

✔️ @RequestMapping
[참고] https://dzone.com/articles/using-the-spring-requestmapping-annotation

 

✔ DTO의 사용 목적

• HTTP 요청의 수를 줄이기 위함 (가장 중요한 목적)
  ➜ 그 요청에 사용되는 비용을 줄이기 위해

 

✔ DTO의 단점

• DTO 클래스를 만들 때 해당 Contoller 클래스 안의 DTO 클래스 생성이 가능한 핸들러 메서드의 개수만큼 생성하게 되는데,
• Controller 클래스가 늘어남에 따라 우리가 작성할 DTO 클래스도 두배로 늘어나게 됨 !!

➜ 이 부분은 공통된 멤버 변수의 추출 및 내부 클래스를 사용하여 어느정도 개선이 가능 !

---

✏️ DTO 클래스 적용을 위한 코드 리팩토링 과정

1. 각 핸들러 메서드의 요청 데이터를 받을 DTO 클래스 생성
( 여기서 DTO 클래스 생성이 가능한 핸들러 메서드는 리소스의 추가가 발생할 때만 가능

Ex. POST , PATCH, PUT 등

2. 요청 데이터 항목들을 DTO 클래스의 멤버 변수로 추가 하고, 각 멤버 변수에 해당하는 getter 추가

But, setter 메서드는 필요에 의한 선택사항 !
setter 메서드 없이 getter 메서드만 있어도 JSON ➜ 객체 의 변환이 가능 !
[참고] https://stackoverflow.com/questions/70955984/why-requestbody-works-without-setters

3. 핸들러 메서드 안의 @RequestParam 쪽 코드를 DTO 객체로 수정

4. Map 객체로 작성되어 있는 Response Body 를 DTO 클래스 객체로 변경

💡 포스트맨으로 잘 전달받고 있는지 확인할 때,
전달 받는 HTTP Request Body가 JSON 형식이어야 하기 때문에
클라이언트 쪽에서 전달하는 Request Body 역시 JSON 형식으로 입력 해야 함

---

✔️ @RequestBody 애너테이션

• JSON 형식의 Request Body ➜ MemberPostDto 클래스의 객체로 변환
  ( 여기서 Request Body - 클라이언트에게 받은 요청 데이터 )
• JSON 형식이 아닌 다른 형식의 데이터를 전송할 경우, 에러 메세지를 포함한 응답을 전달

- @RequestBody로 요청을 받는다는 것
➜ JSON 형식으로 받아서 반환

- @RequestParam으로 요청을 받는다는 것
➜ JSON 형식이 아닌 key value 형식을 받아서 반환

✔️ @ResponseBody 애너테이션

• DTO 클래스의 객체 ➜ Response Body로 변환
  ( 여기서 Response Body - 클라이언트에게 보낼 응답 데이터 )

💡 Spring MVC에서 핸들러 메서드에 @ResponseBody 애너테이션이 붙거나, 핸들러 메서드의 리턴값이 ResponseEntity일 경우
내부적으로 HttpMessageConverter가 동작하게 되어 응답 객체를 JSON 형식으로 바꿔줌
⠀
( 리턴값이 ResponseEntity일 경우 @ResponseBody 애너테이션 붙이면 자동으로 바꿔줌 )

✔️ JSON 직렬화(Serialization)

Java 객체 → JSON 형식

✔️ JSON 역직렬화(Deserialization)

JSON 형식 → Java 객체}

⠀
( ❗ 여기서 Java 객체란 DTO 같은 클래스를 말하는 것 ! )

---

✏️ 유효성(Validation) 검증

• 일반적으로 클라이언트에게 요청 데이터가 전달될 때, 우리한테 넘어오는 그 데이터는 1차적으로 유효성 검증이 진행된 데이터임
  But, 이 값을 조작할 수 있어 반드시 유효한 값이라 볼 수 없기 때문에
  서버 쪽에서 반드시 한번 더 유효성 검사를 해야함
  
  
• 서버 쪽에서 유효한 데이터를 전달 받기 위해 데이터를 검증하는 것

💡 핸들러 메서드 내에 유효성 검증을 하게 되면, 요청 데이터의 개수만큼 메서드 내에 검증 로직이 넘쳐나게 됨
➜ 코드 복잡도 높아짐
⠀
핸들러 메서드는 요청을 전달받는 것이 주 목적이라 최대한 간결하게 작성해야하기에
⠀
DTO 클래스와 유효성 검증 애너테이션을 이용하여
유효성 검증 로직을 DTO 클래스로 빼내어 핸들러 메서드의 간결함 유지 가능
⠀
💡 DTO 클래스에서 유효성 검증 시,
클라이언트의 요청 데이터에 유효하지 않은 데이터가 있다면 유효성 검증에 실패
➜ 클라이언트의 요청이 거부됨

 

✔ 유효성(validation) 검증 애너테이션의 사용

• Spring Boot 2.3버전부터 javax.validation이 spring-boot-starter-web에 포함되어 있지 않기 때문에,
  build.gradle의 dependencies 항목에 따로 아래의 의존성을 추가해줘야 아래의 애너테이션들을 사용 가능함 ⬇️

  implementation 'org.springframework.boot:spring-boot-starter-validation'

 

✔️ java.validation 애너테이션

• @NotNull - Null 불가
• @Null - Null만 입력 가능
• @NotEmpty - Null, 빈 문자열 불가
• @NotBlank - Null, 빈 문자열, 스페이스만 있는 문자열 불가 ( String 타입에만 사용 )
• @Size(min =,max =) - 문자열, 배열등의 크기 지정
• @Pattern(regex =) - 정규식을 만족하는가
• @Max(숫자) - 받을 수 있는 최대값 지정
• @Min(숫자) - 받을 수 있는 최솟값 지정
• @Future - 현재 보다 미래의 순간(날짜, 시간)만 받도록 지정
• @Past - 현재 보다 과거의 순간(날짜, 시간)만 받도록 지정
• @Positive - 양수만 가능
• @PositiveOrZero - 양수와 0만 가능
• @Negative - 음수만 가능
• @NegativeOrZero - 음수와 0만 가능
• @Email - 이메일 형식만 가능
  [참고] https://en.wikipedia.org/wiki/Email_address
• @Digits(integer =, fraction =) - 대상 수가 지정된 정수와 소수 자리 수 보다 작은가?
• @DecimalMax(value =) - 지정된 값(실수) 이하인가?
• @DecimalMin(value =) - 지정된 값(실수) 이상인가?
• @AssertFalse - 값을 false만 받도록 지정
• @AssertTrue - 값을 true만 받도록 지정
  
  ⠀⠀
  ( 위의 애너테이션들을 모두 Jakarta Bean Validation이라는 유효성 검증을 위한 표준 스펙에서 지원하는 내장 애너테이션들임 )

✔️ 각 애너테이션에는 공통적으로 message 속성 적용 가능
( message - 유효성 검사에 실패할 경우, 렌더링 되는 메시지 )
Ex. @NotNull (message = "해당 값이 Null입니다.")

---

✔️ 유효성 검증 애너테이션이 추가된 DTO 클래스에서 유효성 검증 로직이 실행되게 하기 위해서는
해당 Contoller 클래스의 핸들러 메서드 파라미터에 @Valid 애너테이션을 추가해야함

---

✔️ 핸들러 메서드의 URI path에서 사용되는 Id의 유효성 제한을 두는 @PathVariable 애너테이션이 붙을 경우,
클래스 레벨에 @Validated 애너테이션을 반드시 붙여주어야함

[참고] https://immose93.tistory.com/139
[참고] https://hyeran-story.tistory.com/81

✔️ Jakarta Bean Validation

• 라이브러리처럼 사용할 수 있는 API가 아닌 스펙(사양, Specification) 자체
• 이 스펙을 구현한 구현체가 Hibernate Validator
  ➜ Java Bean 스펙을 준수하는 Java 클래스라면 Jakarta Bean Validation의 애너테이션을 사용해서 유효성 검증을 할 수 있다 !

 

✔ 정규표현식 (Reqular Experssion)

[정규표현식 참고 링크]
https://www.w3schools.com/java/java_regex.asp
https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Regular_Expressions
https://learn.microsoft.com/ko-kr/dotnet/standard/base-types/best-practices
https://moonong.tistory.com/31
https://jamesdreaming.tistory.com/201
https://highcode.tistory.com/6

Ex. “^\\S+(\\s?\\S+)*$” ➜ 문자열들 사이에 공백 0~1개만 허용

---

✏️ Custom Validator

• 내 목적에 맞는 애너테이션이 Jakarta Bean Validation에 내장된(Built-in) 애너테이션 중에 없을 수 있음
  ➜ 직접 만들어서 유효성 검증에 적용 가능 !

💡 정규 표현식(Regular Expression)은 성능적인 면에서 때로는 비싼 비용을 치뤄야 될 가능성이 있음
➜ 모든 로직을 정규표현식 위주로 작성하는 것은 좋은 개발 방식이 아니기에
상황에 따라 Custom Validator 사용하기

 

✔️ Custom Validator를 구현하기 위한 절차

1. Custom Annotation을 정의
2. 정의한 Custom Annotation에 바인딩 되는 Custom Validator 구현
3. 유효성 검증이 필요한 DTO 클래스의 멤버 변수에 Custom Annotation 추가

---

😜 DTO 추가 실습

• projects 폴더 Section2-Week1 참고 !

---

🌈 느낀점

어제 오늘 직접 해보고 포스트맨으로 확인해보는게 재밌었다 !!ㅎㅎ

 

( 본 게시물은 2022/10/23에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90