[데브코스] Spring Boot REST API 실습 (24강) - PostWriteForm → PostWriteReqBody로 이름 변경

이번 강의에서는 기능적인 변화보다는
REST API 설계 관점에서의 네이밍과 요청 처리 방식을 정리하는 시간이었다.

겉보기엔 변경 사항이 적어 보이지만,
REST API를 제대로 이해하기 위해서는 꼭 짚고 넘어가야 할 내용이다.

---

1️⃣ PostWriteForm → PostWriteReqBody로 이름 변경

기존 코드

record PostWriteForm(
        @NotBlank
        @Size(min = 2, max = 100)
        String title,

        @NotBlank
        @Size(min = 2, max = 5000)
        String content
) {
}

변경된 코드

record PostWriteReqBody(
        @NotBlank
        @Size(min = 2, max = 100)
        String title,

        @NotBlank
        @Size(min = 2, max = 5000)
        String content
) {
}

왜 이름을 바꿨을까?

Form이라는 이름은 보통 HTML form 기반 요청을 연상시킨다.

하지만 지금 우리가 구현하는 것은:

• 타임리프 기반 서버 사이드 렌더링 ❌
• REST API 기반 JSON 요청 ⭕

즉, 이 객체는 화면 폼(Form) 이 아니라
👉 HTTP 요청의 Body(JSON) 를 그대로 표현하는 객체다.

그래서 강사님은
PostWriteForm 보다 PostWriteReqBody가 의미상 더 정확하다고 설명하셨다.

이름만 봐도
“아, 이건 요청 바디(JSON)를 받는 객체구나”
를 바로 알 수 있어야 한다는 의미다.

---

2️⃣ record가 컨트롤러 내부 클래스여도 문제없는 이유

현재 구조는 다음과 같다.

@RestController
@RequestMapping("/api/v1/posts")
@RequiredArgsConstructor
public class ApiV1PostController {

    // 생략

    record PostWriteReqBody(
            String title,
            String content
    ) {
    }

    @PostMapping
    @Transactional
    public RsData<PostDto> write(
            @Valid @RequestBody PostWriteReqBody form
    ) {
        Post post = postService.write(form.title(), form.content());

        return new RsData<>(
                "200-1",
                "%d번 글이 생성되었습니다.".formatted(post.getId()),
                new PostDto(post)
        );
    }
}

record가 내부 클래스여도 상관없다

• record는 그냥 불변 DTO
• 내부 클래스든, 별도 파일이든 동작 방식은 동일
• 단지 이 컨트롤러에서만 쓰는 요청 DTO라면 내부에 두는 것도 충분히 합리적이다

“이 API 전용 요청 바디”라는 의도가 코드 구조에서도 드러난다.

---

3️⃣ REST API 요청을 받으려면 무조건 @RequestBody가 필요할까?

결론부터 말하면 ❗

JSON 요청 바디를 받을 때는 거의 무조건 필요하다.

---

@RequestBody가 하는 역할

@Valid @RequestBody PostWriteReqBody form

이 한 줄에서 일어나는 일:

1. 클라이언트가 보낸 JSON 요청 바디를 읽는다
2. Jackson이 JSON → Java 객체로 변환한다
3. 변환 결과를 form에 주입한다
4. @Valid가 붙어 있으므로 유효성 검사 수행

---

만약 @RequestBody를 빼면?

public RsData<PostDto> write(PostWriteReqBody form)

이 경우 Spring은 이렇게 생각한다.

“이건 요청 바디가 아니라
쿼리 파라미터나 form-data겠네?”

결과적으로:

• JSON body는 읽지 않는다
• form은 null이거나
• 바인딩 에러 발생

즉, REST API + JSON 요청 조합에서는
👉 @RequestBody는 사실상 필수다.

---

4️⃣ 언제 @RequestBody를 안 써도 되나?

아래 같은 경우에는 사용하지 않는다.

✔ Query Parameter

GET /posts?page=1&size=10

@GetMapping
public List<PostDto> getItems(
        @RequestParam int page,
        @RequestParam int size
)

---

✔ Path Variable

GET /posts/1

@GetMapping("/{id}")
public PostDto getItem(@PathVariable int id)

---

✔ HTML Form 기반 요청 (타임리프 등)

@PostMapping("/write")
public String write(PostWriteForm form)

이 경우는 @RequestBody ❌
(서버 사이드 렌더링 전제)

---

5️⃣ 정리

• PostWriteForm → PostWriteReqBody
  • REST API 요청 바디라는 의미를 명확히 하기 위함
• record는 컨트롤러 내부에 있어도 문제 없음
• record는 getter 없이도 form.title() 형태로 접근 가능
• JSON 기반 REST API 요청을 받으려면 @RequestBody는 필수
• @RequestBody는 JSON → Java 객체 변환의 핵심

---

💡 한 줄 요약

REST API에서 DTO 이름은 의도를 드러내는 문서이고,
JSON 요청을 받는다면 @RequestBody는 선택이 아니라 기본이다.