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

현주·2022년 10월 22일

spring mvc 실습 코드스테이츠

bootcamp

목록 보기

42/71

📕 오늘 배운 내용!

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 클래스 적용을 위한 코드 리팩토링 과정

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

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

But, setter 메서드는 필요에 의한 선택사항 !
setter 메서드 없이 getter 메서드만 있어도 JSON ➜ 객체 의 변환이 가능 !
[참고] https://stackoverflow.com/questions/70955984/why-requestbody-works-without-setters
핸들러 메서드 안의 @RequestParam 쪽 코드를 DTO 객체로 수정
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를 구현하기 위한 절차

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

✏️ DTO 추가 실습

projects 폴더 Section2-Week1 참고 !

🌈 느낀점

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

현주

이전 포스트

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

다음 포스트