ㅇ JSON 문자열을 MAP으로
//MemberController에서
System.out.println()"# email: " + email);
System.out.println()"# name: " + name);
System.out.println()"# phone: " + phone);
String response =
"{\"" +
"email\":\""+email+"\"," +
"\"name\":\""+name+"\",\"" +
"phone\":\"" + phone+
"\"}";
return response;
//위 코드 JSON 문자열 수작업을 MAP 객체로 대체한다.
Map<String, String> map = new HashMap<>();
map.put("email", email);
map.put("name", name);
map.put("phone", phone);
return ne ResponseEntity<>(map, HttpStatus.CREATED);
//위 코드로 대체함.
그리고 나머지 mapping메서드에도
리턴값을
return ne ResponseEntity<>(HttpStatus.OK);
로 대체한다.
그리고 @RequestMapping도 수정한다.
@RequestMapping(value = "/v1/members", produces = {MediaType.APPLICATION_JSON_VALUE})
//위 코드에서 produces 삭제
@RequestMapping(value = "/v1/members")
ㅇ @RequestHeader로 헤더 정보 얻기
@PostMapping
public ResponseEntity postMember(@RequestHeader Map<String, String> headers,//여기서
@RequestParam("email") String email,
@RequestParam("name") String name,
@RequestParam("phone") String phone) {
for (Map.Entry<String, String> entry : headers.entrySet()) {
System.out.println("key: " + entry.getKey() +
", value: " + entry.getValue());
}
return new ResponseEntity<>(new Member(email, name, phone),
HttpStatus.CREATED);
}
@RequestHeader로 전제 헤더정보를 얻어온다.
ㅇ HttpServletRequest 객체로 헤더 정보 얻기
@PostMapping
public ResponseEntity postOrder(HttpServletRequest httpServletRequest,//여기서
@RequestParam("memberId") long memberId,
@RequestParam("coffeeId") long coffeeId) {
System.out.println("user-agent: " + httpServletRequest.getHeader("user-agent"));
return new ResponseEntity<>(new Order(memberId, coffeeId),
HttpStatus.CREATED);
}
HttpServletRequest 객체를 통해 "user-agent"정보 출력함.
ㅇ DTO(Data Transfer Object)
기존 postMember() 핸들러 메서드에서 회원정보를 저장하기 위해 @RequestParam을 사용하는데 데이터는 더 많아질수도있다. 그럴때마다 @RequestParam을 사용하는것은 비효율적이다. 이런 회원정보들을 DTO클래스로 하나의 객체로 전달받으면 매우 간결해진다!
public class MemberDto {
@Email
private String email;
private String name;
private String phone;
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPhone() {
return phone;
}
public void setPhone(String phone) {
this.phone = phone;
}
}
이렇게 DTO클래스를 만들고
@PostMapping
public ResponseEntity postMember(MemberDto memberDto) {
return new ResponseEntity<MemberDto>(memberDto, HttpStatus.CREATED);
}
Dto객체로 받아오면 훠엉어ㅓㅇ얼씬 깔끔해지는 기적이 펼쳐진다!
그리고 Dto클래스를 쓰면 유효성 검증이 굉장히 단순해진다.
위의 MemberDto 클래스에 @email 애너테이션을 보면
유효하지 않은 email 형식을 받는걸 사전차단할 수 있다.
이러한 유효성 검증은 프런트에서 먼저 검증하지만 프런트에서 검증됐다고 해서 꼭 유효한 값으로 볼 수 없다.
고로! Dto클래스를 사용해 유효성 검증을 해야한다.
@email 애너테이션말고 진짜로 검증을 해보자!
먼저, build.gradle에서 dependencies추가
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-validation'
...
...
}
수정된 MemberPostDto
public class MemberPostDto {
@NotBlank
@Email
private String email;
@NotBlank(message = "이름은 공백이 아니어야 합니다.")
private String name;
@Pattern(regexp = "^010-\\d{3,4}-\\d{4}$",
message = "휴대폰 번호는 010으로 시작하는 11자리 숫자와 '-'로 구성되어야 합니다.")
private String phone;
. . . //이하 동문
}
살펴보자.
email은 공백을 받을 수 없다. -- @NotBlank, 유효한 email형식 -- @Email
phone의 @Pattern은 정규표현식을 사용했다.
ㅇ MemberPatchDto
public class MemberPatchDto {
private long memberId;
// 공백 아닌 문자 1개 이상((공백인 문자 0개 또는 1개)(공백이 아닌 문자 1개 이상)) -> 마지막 맨 바깥 쪽 괄호 조건이 0개 이상(즉, 있어도 되고 없어도 된다)
@Pattern(regexp = "^\\S+(\\s?\\S+)*$", message = "회원 이름은 공백이 아니어야 합니다.")
private String name;
@Pattern(regexp = "^010-\\d{3,4}-\\d{4}$",
message = "휴대폰 번호는 010으로 시작하는 11자리 숫자와 '-'로 구성되어야 합니다.")
private String phone;
. . . //이하 동문
}
이 클래스를 사용하는 MemberController의 patchMember() 핸들러 메서드
@PatchMapping("/{member-id}")
public ResponseEntity patchMember(@PathVariable("member-id") @Min(2) long memberId,
@Valid @RequestBody MemberPatchDto memberPatchDto) {
memberPatchDto.setMemberId(memberId);
// No need Business logic
return new ResponseEntity<>(memberPatchDto, HttpStatus.OK);
}
위의 메서드에서 파라미터로 @PathVariable("member-id") @Min(2) long memberId 는 2이상의 숫자여야만 유효성 검증에 통과함.
@PathVariable을 유효성 검증하려면 클래스레벨에 @Validated 추가해야함!!!
위에서 사용한 유효성검증 애너테이션들은 Jakarta Bean Validation에서 지원하는 내장 애너테이션들이다.
다음시간에 계속! 4편에서 봐요~
'부트캠프 > 백' 카테고리의 다른 글
클라우드 운영전략 (0) | 2023.02.07 |
---|---|
Github Actions (0) | 2023.02.06 |
자동배포방식 - Pipeline (0) | 2023.02.04 |
Docker - container (0) | 2023.02.03 |
Section3-2 (0) | 2023.02.01 |