반응형
@ SpringBoot
@ JDK 21
REST API에서 요청 DTO를 매번 만들어야 하나?
왜 요청 DTO를 쓰는가?
REST API를 처음 설계할 때, 객체를 남발하는 느낌과 굳이 필요한가? 만약, 하나의 요청값만 있다면 너무 too much 아닌가? 라는 생각이 들었다.
다만, 결론만 생각해본다면 DTO는 많은게 맞고, 그만큼 얻는게 많다는 것이다.
- 도메인을 외부 API에 노출하지 않는다.(API 안정성 증가)
- 도메인과 분리되어 결합도를 낮춰 개발 영향도가 적다.
- DTO 클래스에 검증 어노테이션 등을 사용해서 간결하게 처리 가능하다.
- 위 내용을 토대로 유지 보수 관점에서도 좋다.
그래도 너무 많고 아무리 DTO를 권장해도 파일이 너무 많거나 정리를 못하여 복잡해진다면
대안법으로 사용할 만한 방법이 몇가지 있다.
공통/재사용 가능한 DTO로 분리
// 재사용 DTO 객체
public class UserCredentials {
private String email;
private String password;
}
// 중첩 DTO
public class LoginRequest {
private UserCredentials credentials;
}
검색 조건용 DTO는 하나로 묶기
여러 DTO를 사용하는게 아닌 하나의 DTO로 사용
public class UserSearchCondition {
private String name;
private Integer minAge;
private Integer maxAge;
}
단순 요청은 Map이나 record로 처리
Map의 단점은 타입 안정성, Validation, Swagger 문서화 등에서 불리하다.
한편, JDK 14에 등장하고, 16부터 정식으로 등록됐고, JDK 21 부터 기준으로 사용된 record를 사용하는 것이 DTO 쓰기에 최적이다.
21 이상이라면 record를 사용하자.
@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody Map<String, String> body) {
String email = body.get("email");
String password = body.get("password");
...
}
public record LoginRequest(String email, String password) {}
결론
✅ JDK 21 이상이면 record를 사용하자.
✅ DTO 사용 권장
✅ 도메인 객체로 API에 직접 주고 받지 말자.
반응형
'Java' 카테고리의 다른 글
[스프링부트] 하나의 인터페이스로 여러 구현체 선택 방법 (0) | 2025.03.27 |
---|---|
[Java] record는 뭐야? (1) | 2025.03.25 |
REST API 설계, GET 방식과 보안이슈 (0) | 2025.03.25 |
Java 버전별 변천사 ( Java 6 ~ ) (2) | 2025.03.15 |
자바의 특징 (0) | 2025.03.13 |