스프링 API RequestDTO 구조/설계에 대한 정리

스프링에서 API RequestDTO 구조 설계를 어떻게 해야하는지에 대해 알아보고 싶은게 있어서 정리한다.

일단 requestBody 어노테이션을 통해서 요청 DTO를 처리 할때 List 형태로 받는것이 맞는 것인지 DTO 클래스 안에 List를 정의해서 받는 것이 맞는 것 일지 궁금증이 생겼다.

✅ 1. @RequestBody List로 받는 것 — 가능함

@PostMapping("/test")
public ResponseEntity<Void> test(@RequestBody List<DTO> request) {
    ...
}

✔ 장점

• 구조가 단순해서 한번에 여러 DTO를 보낼 때 직관적이다
• 불필요한 wrapper 객체가 필요 없다,.
  ✔ 단점
• 확장성(추가 필드 필요시)이 떨어진다.
• 특정기업/서비스의 공통 API 규약과 충돌이 날 수 있다.
  → 많은 기업은 항상 객체 기반 JSON을 요구 (배열 루트 구조 금지)\

✅ 2. DTO 안에 List를 포함해서 받는 것 — 조직·확장성 좋은 구조

@PostMapping("/test")
public ResponseEntity<Void> test (@RequestBody TestRequest request) {
    ...
}
public class TestRequest {
    private List<DTO> tests;
}

✔ 장점

• 확장이 매우 쉽다.
• API 문서화 및 버전 관리가 용이하다.
• 대부분의 회사/플랫폼 API 규칙과 일관성 있다.
  ✔ 단점
• 단순 배열 요청보다 구조가 한단계 깊어진다.

✅결론 요약을 하자면