트러블 슈팅 - 팔로우 기능의 분리

📓뉴스피드 API Github

팔로우 기능의 분리

초기 설계

• 하나의 URI 로 팔로우/언팔로우 기능을 구현했다.
• 요청 URI : POST /users/{id}/follow
• 로그인한 사용자(User)의 ID와 대상 사용자의 ID를 받음
  • 이미 팔로우 상태면 → 언팔로우 (삭제)
  • 팔로우 상태가 아니면 → 팔로우 (추가)

문제점

• REST 원칙에 어긋남
  • POST는 리소스 생성(create) 목적의 메서드인데, 해당 URI에서 삭제(delete) 동작까지 처리하고 있다.
  • 따라서 클라이언트 요청의 의도가 불분명해지고, REST 설계 원칙에 어긋난다.
• 단일 책임 원칙에 어긋남 (Single Responsibility Principle)
  • 하나의 메서드가 두개의 책임을 지고있다.
  • 유지보수나 확장 시에 하나의 변경이 다른 책임에 영향을 줄 수 있는 구조다.
• 예외 처리가 복잡해짐
  • 이미 좋아요를 눌렀는데 또 누르려 하면 → 409 Conflict 발생 가능
  • 좋아요를 취소하려는데 아직 누르지 않았으면 → 404 Not Found 발생 가능
  • 단위 테스트와 통합 테스트 시 시나리오가 많아지고, 가독성이 떨어진다.

해결

• 기능을 분리하여 각각의 API로 나누고, 각 요청의 의도를 명확히 전달하도록 설계 변경
  • POST /users/{id}/follow → "팔로우"
  • DELETE /users/{id}/follow → "언팔로우"

장점

• 클라이언트는 요청만으로 행위의 의도(팔로우 또는 언팔로우)를 명확히 표현할 수 있음
• 컨트롤러와 서비스 로직이 각각 단일 책임 원칙(SRP)을 따르게 되어 유지보수가 쉬워짐
• RESTful API 설계 원칙에 부합하여 가독성과 일관성이 향상됨
• 테스트 시 각 동작에 대한 검증이 독립적이고 단순해짐