이번 강의는 앞에서 구현했던 글 수정 API를 그대로 확장해서
댓글 수정 API를 구현하는 강의였다.
구조도 흐름도 이미 익숙한 패턴이라
“아, 이제 이건 손에 익었다”는 느낌이 드는 단계다.
📌 이번 강의의 핵심 포인트
- 댓글 수정은 PUT 요청
- 입력값은 JSON →
@RequestBody - 유효성 검사는
@Valid - 성공/실패만 알리므로
RsData<Void> - 댓글은 항상 글(Post)에 종속된 엔티티
🧱 댓글 수정 입력 DTO
record PostCommentModifyReqBody(
@NotBlank
@Size(min = 2, max = 100)
String content
) {
}왜 DTO를 따로 만들까?
- JSON 요청을 명확하게 표현
- 수정 가능한 필드만 열어두기
- 엔티티 직접 노출 방지
📌 댓글 수정은 content 하나만 바뀌므로
DTO도 그에 맞게 최소한으로 구성한다.
🔧 댓글 수정 API 전체 코드
@PutMapping("/{id}")
@Transactional
public RsData<Void> modify(
@PathVariable int postId,
@PathVariable int id,
@Valid @RequestBody PostCommentModifyReqBody reqBody
) {
Post post = postService.findById(postId).get();
PostComment postComment = post.findCommentById(id).get();
postService.modifyComment(postComment, reqBody.content);
return new RsData<>(
"200-1",
"%d번 댓글이 수정되었습니다.".formatted(id)
);
}🔍 코드 흐름을 한 줄씩 풀어보면
1️⃣ 어떤 글의 댓글인지 먼저 찾는다
Post post = postService.findById(postId).get();- 댓글은 단독으로 존재하지 않음
- 항상 Post → Comment 구조
2️⃣ 해당 글에서 댓글을 찾는다
PostComment postComment = post.findCommentById(id).get();👉 이 구조의 장점
- “이 댓글이 정말 이 글에 속해 있는가?”
- 자연스럽게 검증 가능
- URL 구조와 도메인 구조가 일치
3️⃣ 댓글 내용 수정
postService.modifyComment(postComment, reqBody.content);- 비즈니스 로직은 서비스 계층에서 처리
- 컨트롤러는 흐름만 담당
4️⃣ 응답은 RsData
return new RsData<>(
"200-1",
"%d번 댓글이 수정되었습니다.".formatted(id)
);- 수정 결과 데이터는 필요 없음
- 성공 여부 + 메시지만 전달
- 그래서
RsData<Void>
🤔 왜 200 OK 인가?
- PUT 요청의 의미: 기존 리소스 수정
- 수정 성공 →
200 OK가 가장 자연스럽다 201 Created는 생성일 때만 사용
🧠 이번 강의에서 정리되는 패턴
댓글 관련 API 공통 패턴
- 상위 엔티티(Post) 조회
- 하위 엔티티(Comment) 조회
- 서비스 계층에서 처리
- RsData로 결과 반환
✍️ 마무리 정리
- 댓글 수정도 글 수정과 완전히 같은 구조
- JSON 입력 → ReqBody DTO
- 응답은 RsData
- 댓글은 항상 글에 종속된 리소스
- 구조가 반복된다는 건 설계가 안정됐다는 신호
💬 개인적인 느낀 점
이제는 새로운 API를 봐도
“어디서 DTO 만들고,
어디서 서비스 호출하고,
어떤 RsData를 반환할지”
머릿속에 바로 그려진다.
이 단계부터는
👉 기능 추가보다 설계 감각이 쌓이는 구간이라는 느낌이 든다.
