API 설계 – 생성 후 어떤 응답을 반환할까? (ID vs DTO)

“POI 생성 API를 개발하다가 이런 고민이 들었다.
생성 후 ID만 반환할까? 아니면 방금 생성한 POI 데이터를 그대로 돌려줄까?

상황별로 어떤 방식이 더 적합할지 정리해봤다.”

---

1. 고민의 시작

최근 공간 기반 서비스 개발을 하면서, POI(장소) 생성 API를 만들었다.
그런데 여기서 고민이 생겼다.

• 옵션 1 → ID만 반환
• 옵션 2 → DTO(엔티티 데이터) 반환

두 방식 모두 많이 쓰인다.
하지만 상황에 따라 장단점이 분명히 갈린다고 판단했다.

 

---

2. ID만 반환하는 방식

✅ 예시

 

@PostMapping
fun createPoi(@RequestBody request: CreatePoiRequest): ResponseEntity<Long> {
    val poiId = poiService.createPoi(request)
    return ResponseEntity.ok(poiId)
}

 

✅ 장점

• 응답 데이터가 가볍고 단순하다.
• 생성과 조회를 명확히 분리할 수 있다.
• REST 설계 원칙에 충실하다.
  → POST → 201 Created → 이후 GET으로 상세 조회

 

✅ 단점

• 프론트엔드에서 바로 데이터가 필요하면 한 번 더 조회 API를 호출해야 한다.
• 즉각적인 화면 갱신이 필요한 SPA(React, Vue 등)에선 번거롭다.

 

✅ 이런 상황에 적합

• 트래픽이 큰 서비스 → 불필요한 데이터 전달 최소화
• “생성”과 “조회” 책임을 깔끔히 나누고 싶은 팀
• 비즈니스 로직 상, 생성 직후 추가 확인이 필요 없는 경우

 

---

 

3. DTO 반환 방식

✅ 예시

@PostMapping
fun createPoi(
    @RequestBody @Valid request: CreatePoiRequest
): ResponseEntity<PoiResponse> {
    val poi = poiService.createPoi(request)
    return ResponseEntity.ok(poi)
}

 

✅ 장점

• 프론트가 즉시 데이터 활용 가능
  • 예: 상세 페이지 이동, UI 반영
• API 호출 수를 줄일 수 있음.
• 디버깅할 때도 응답에 정보가 많아 편리하다.

 

✅ 단점

• 데이터 크기가 커질 수 있음.
• 엔티티가 복잡하면 응답 관리가 어려울 수 있음.

 

✅ 이런 상황에 적합

• SPA에서 즉시 화면 갱신이 필요한 경우
• 생성 직후 상세 정보를 사용자에게 보여주고 싶을 때
• API 호출 수를 줄이고 싶은 프로젝트

 

---

 

4. 실제 내가 고민한 포인트

“왜 굳이 ID만 반환할까?
방금 만든 데이터를 곧바로 반환하면 좋지 않나?”

처음엔 나도 DTO 반환을 선호했다.
프론트 입장에서 당연히 편하니까!

그런데 팀이나 프로젝트 상황을 생각하니 ID 반환도 장점이 분명했다.

• 트래픽 최소화가 필요한 대형 서비스라면?
• 생성 직후 데이터를 무조건 다시 확인해야 한다면?
• 데이터 구조가 너무 복잡하다면?

이럴 땐 ID만 주고, 클라이언트가 GET으로 다시 조회하는 게 더 나은 설계다.

 

---

 

5. 정리

	ID 반환	DTO 반환
응답 크기	작음	커질 수 있음
프론트 편의성	불편 (한 번 더 조회)	편리 (바로 사용 가능)
REST 설계 관점	정석적	유연함
API 호출 수	늘어남	줄어듦

 

---

 

✅ 결론

• ID 반환 → 단순, REST 원칙 지키고 싶을 때
• DTO 반환 → 즉시 화면 갱신, 프론트 편의성 중시할 때

나는 이번 프로젝트에선 DTO 반환으로 결정했다.
왜냐하면

• POI 데이터가 크지 않음.
• 프론트에서 등록 직후 바로 데이터를 써야 함.
• 호출 수 줄이는 게 중요하기 때문!

 

---

 

💡 한 줄 정리

“데이터를 곧바로 써야 하면 DTO 반환하고,
트래픽 관리·REST 원칙을 지키고 싶다면 ID 반환하자.”