MinChur

부트캠프 회고: 프로젝트 설계와 API 명세서 작성 (Part 2)

|
1 min read

본격적인 프로젝트 시작 전, API 명세서 설계와 협업을 위한 피드백 과정을 통해 깨달은 설계의 중요성을 공유합니다.

1. API 명세서 설계: 상품 도메인

저는 이번 프로젝트에서

text
상품
도메인을 맡았습니다. 기본적인 CRUD를 설계하면서 카테고리별 조회, 특정 가게의 상품 등록 등 실제 서비스에서 발생할 수 있는 유즈케이스를 고려했습니다.

  • 주요 API:
    • text
      POST /products/stores/{storeId}
      (상품 등록)
    • text
      GET /products/stores/{storeId}/categories
      (카테고리 조회)
    • text
      DELETE /products/{productId}
      (상품 삭제)

2. 치열한 피드백과 통일성

각자 맡은 도메인을 설계하다 보니 전체적인 통일성이 깨지는 문제가 있었습니다. 멘토님의 피드백을 통해 많은 것을 바로잡을 수 있었습니다.

  • URL 규칙: 단수/복수 혼용을 방지하고
    text
    /products
    와 같이 명확한 명사형을 사용하기로 했습니다.
  • 리소스 계층 구조: 회원 주소는
    text
    /address
    가 아닌
    text
    /users/address
    와 같이 소유 관계를 명확히 표현해야 함을 배웠습니다.
  • PATCH vs PUT: 전체 수정을 의미하는 PUT과 달리, 부분 수정을 위한 PATCH의 용도를 명확히 구분하여 적용했습니다.

3. 협업의 가치

같은 주제라도 조마다 설계 방식이 천차만별이었습니다. 다른 팀의 결과물을 보며 "아, 저런 접근 방식도 있구나"라며 시야를 넓힐 수 있었습니다. 결제 로직 설계 시 실제 PG사와의 통신 흐름을 고려해야 한다는 점 등 기술적인 깊이도 더해진 시간이었습니다.