[4주차] 임현성/[feat] 추가 API 구현

[HyeonSeongIM]

1. 과제 요구사항 중 구현한 내용

• 프로젝트 구조 구성 (Controller/Service 레이어 분리)
• 헬스체크 API 구현 (GET /health)
• 문자열 2개 반환 API 구현 (POST /string/repeat)
• 권장 추가 구현 반영 (선택)

2. 핵심 변경 사항

• Report 도메인 추가

  • 게시물/댓글 신고 API 구현
  • 신고 상태(PENDING → RESOLVED) 변경 API 구현
  • 신고 대상(Post/Comment) 분리 설계

• Like 도메인 추가

  • 게시글 좋아요 생성 API 구현
  • 동일 유저의 동일 게시글 좋아요 중복 방지 로직 구현

• 단순 CRUD를 넘어 상태 변경 및 중복 방지 로직 포함한 비즈니스 로직 설계

3. 실행 및 검증 결과

• 실행 결과:

  • 애플리케이션 정상 실행 및 API 정상 동작 확인

• GET /health 응답:
  {
  "status": "OK"
  }

• POST /string/repeat 요청:
  {
  "string1": "hello",
  "string2": "world"
  }

• POST /string/repeat 응답:
  {
  "result": "helloworld"
  }

• 주요 기능 검증:

1. 게시물 신고
   POST /api/posts/{postId}/reports
   → 신고 생성 및 상태 PENDING 확인

2. 댓글 신고
   POST /api/comments/{commentId}/reports
   → 댓글 대상 신고 정상 생성

3. 신고 처리 완료
   PATCH /api/reports/{reportId}/resolve
   → PENDING → RESOLVED 상태 변경 확인

4. 게시글 좋아요
   POST /api/posts/{postId}/likes
   → 최초 요청 시 정상 생성
   → 동일 유저 재요청 시 중복 방지 확인

4. 완료 사항

1. 게시물/댓글 신고 기능 구현
2. 신고 상태 변경(PENDING → RESOLVED) 기능 구현
3. 게시글 좋아요 기능 및 중복 방지 로직 구현
4. Controller / Service 레이어 분리
5. 기본 요구 API(health, string) 구현 완료

5. 추가 사항

• 관련 이슈: closed #이슈번호

• 리뷰 포인트:

  • 신고 도메인 설계 (Post/Comment 분리 방식)
  • 좋아요 중복 방지 로직 처리 방식
  • 상태 변경 API(PATCH) 설계 적절성

제출 체크리스트

• PR 제목이 규칙에 맞다

• base가 {이름}/main 브랜치다

• compare가 {이름}/{숫자}주차 브랜치다

• 프로젝트가 정상 실행된다

• 본인을 Assignee로 지정했다

• 리뷰 피드백을 반영한 뒤 머지/PR close를 진행한다

[HandoA01]

기존에 record 안에서 PostException을 던지던 걸 @NotBlank/@SiZe로 빼고, 주석으로 이유까지 남겨두신 부분 좋네요! DTO에서는 형식 검증만, 비즈니스 검증은 서비스로 옮기는 흐름이 깔끔한 것 같습니다!!

[HandoA01]

4주차 개발도 수고 많으셨습니다 ! :)

[kdobi]

orElseThrow에서 람다식을 활용한 부분이 깔끔하게 잘 작성된 것 같습니다.

[kallin1]

softdelete시에 hidden으로 상태를 변환하고, 신고가 누적될 경우에도 hidden으로 상태변환하시는 것 같은데 두 경우 모두 hidden으로 처리되면 나중에 삭제된건지 신고로 숨겨진건지 구분이 어려울 것 같아요! 혹시 따로 구분가능하게 처리하신 부분이 있나요?