단일 링크 요약 상태 조회 API 구현

[ckdals4600]

관련 이슈

• close 단일 링크 요약 상태 조회 API 개발 #203

PR 설명

API 명세

• Endpoint : GET /v1/links/{id}/summary-status
• Response

      {
        "linkId": 105,
        "status": "PROCESSING",
        "summary": null,
        "errorMessage": null
      }
  

비즈니스 로직

• LinkFacade: 컨트롤러의 요청을 받아 서비스 레이어에 위임하고, 반환된 도메인 상태를 응답 DTO(SummaryStatusRes)로 변환함.
• LinkService:
  • 식별자(ID)와 사용자(Member) 정보를 기반으로 대상 링크의 소유권을 검증함.
  • 해당 링크 엔티티에서 SummaryStatus 필드만 가볍게 추출하여 반환함.
  • 상태값이 null일 경우를 대비해 SUMMARY_STATUS_MISSING 비즈니스 예외 처리 추가함.

[github-actions]

📊 코드 커버리지 리포트

Overall Project	93.36%	🍏
Files changed	100%	🍏

File	Coverage
LinkController.java	100%	🍏
LinkErrorCode.java	100%	🍏
LinkFacade.java	100%	🍏
LinkService.java	100%	🍏

[Goder-0]

@ckdals4600
이슈(#203) 명세는 linkId, status 중심인데,
PR에서는 SummaryStatusRes를 재사용해서 summary, errorMessage까지 같은 스키마로 가고 있네요.
구조가 다른 걸 보면 의도된 설계로 보이는데, 이 방향을 선택한 이유가 궁금합니다.

• 웹소켓/폴링 응답 스키마 통일(개발 속도, 유지보수 단순화) 목적이었는지
• 아니면 summary-status API에서도 정상/예외 상태를 하나의 DTO 관심사로 묶는 게 적절하다고 판단하셨는지

제 관점에서는 현재 DTO가 정상 케이스 + 예외성 상태 표현까지 함께 맡는 구조라, 책임 분리 측면의 의도만 확인되면 좋겠습니다.

[ckdals4600]

@ckdals4600 이슈(#203) 명세는 linkId, status 중심인데, PR에서는 SummaryStatusRes를 재사용해서 summary, errorMessage까지 같은 스키마로 가고 있네요. 구조가 다른 걸 보면 의도된 설계로 보이는데, 이 방향을 선택한 이유가 궁금합니다.

• 웹소켓/폴링 응답 스키마 통일(개발 속도, 유지보수 단순화) 목적이었는지
• 아니면 summary-status API에서도 정상/예외 상태를 하나의 DTO 관심사로 묶는 게 적절하다고 판단하셨는지

제 관점에서는 현재 DTO가 정상 케이스 + 예외성 상태 표현까지 함께 맡는 구조라, 책임 분리 측면의 의도만 확인되면 좋겠습니다.

리뷰 감사합니다!

말씀하신 대로 해당 구조를 선택했던 가장 큰 이유는 웹소켓과 폴링의 응답 스키마를 통일하여 프론트엔드의 파싱 처리를 단순화하기 위함이었습니다. 단일 채널로 여러 상태가 전달되는 웹소켓 특성상, 통합된 스키마를 사용하는 것이 클라이언트 입장에서 예외 처리가 수월할 것이라고 판단했습니다.

하지만 코멘트를 달며 다시 구조를 고민해 보니, 모든 필드를 한 객체에 두기보다는 공통 응답 객체에 제네릭을 도입하는 것이 훨씬 깔끔한 설계가 될 것 같습니다. data 필드에 상황에 따라 summary나 errorMessage를 동적으로 담는 방식으로 분리하여 리팩토링 진행하였습니다!