📚 이번주엔 뭘 배웠지?
- Spring MVC에서 요청(Request)과 응답(Response)의 전체 흐름을 구조적으로 이해했다.
- @Controller, @RestController, @ResponseBody의 역할 차이
- GET 요청의 데이터 전달 방식인 PathVariable vs Query Parameter
- POST 요청에서의 Content-Type별 처리 방식
application/x-www-form-urlencoded
multipart/form-data
application/json - @RequestParam, @ModelAttribute, @RequestBody, @RequestPart의 쓰임새를 상황별로 정리
- JSON 단일 객체, 리스트, 중첩 JSON 구조까지 DTO로 매핑
- DTO → Entity 변환 책임을 Service 계층에서 처리
- HTTP 프로토콜의 구조, 상태코드, Stateless 특성, TCP/IP 개념
- Gradle 빌드 구조와 build.gradle, 의존성 범위의 의미
👊 어떤 문제점이 있었지?
요청 타입과 어노테이션 조합이 헷갈렸다.
(ex. 언제 @RequestBody를 쓰고, 언제 @ModelAttribute를 써야 하는지)
JSON + 파일 업로드 처리에서 multipart + JSON 구조가 직관적이지 않았다.
Controller에서 DTO를 바로 Entity로 쓰고 싶은 유혹이 계속 들었다.
🙏 무엇을 깨달았고, 어떤 생각이 들었지?
- 왜 이렇게 나뉘어 있는지를 이해를 해야 코드방식도 빠르게 이해가 가능했다.
- 요청 데이터 형식이 다르면 서버 설계 방식도 완전히 달라진다는 걸 체감했다.
- DTO를 분리하는 이유가 단순한 규칙이 아니라
👉 책임 분리 + 확장성 + 보안 때문이라는 게 와닿았다. - HTTP, 네트워크, 스프링이 하나의 흐름이라는 느낌이 들었다.
😄 결과적으로, 현재 나의 상태는?
코드를 보면 “아 이건 JSON 바인딩이구나”, “이건 multipart구나” 하고 구조가 보인다.
완벽하진 않지만,
👉 백엔드에서 하는 역할 감이 확실히 잡힌 단계라고 느낀다.
👨🚀 앞으로 어떻게 하는게 좋을까?
강사님이 말씀하신대로 쌍둥이 프로젝트와 이론을 병행하여 무엇이든 설명할수 있을정도로 복습해야겠다고 느꼈다.
코드를 반복하게되도 여러번 까먹고, 또 새로운 관점으로 보일때가 있다.
코드를 읽다가 아래와 같은 개념설명이 부족한 걸 느꼈다.
@PostMapping("/create")
public String create(@RequestBody AuthorCreateDto dto){
authorService.save(dto);
return "ok";
}
위 코드에서 @RequestBody AuthorCreateDto dto ← 이 부분을 "json으로 데이터 받는구나" 라고 덜 정확한 표현을 하게됨.
깔끔하게 설명하자면 “JSON 요청 바디를 DTO 객체로 변환해서 받겠다”는 뜻이다.
① RequestBody를 사용하여 HTTP 요청의 body 부분을 읽고, (※ 쿼리 파라미터(?name=kim)나 path(/author/1)가 아님)
② JSON → DTO 객체로 역직렬화(파싱) 하겠다는 의미
- 클라이언트가 보낸 JSON을 AuthorCreateDto 필드에 맞게 자동으로 객체로 만들어준다.
