[3차 과제] API 분류 (호출 빈도, Read, Write)

[airoca]

✅ API 분류 (호출 빈도, Read, Write)

▶️ 가장 호출이 많을 것 같은 API와 적을 것 같은 api 구분해보기

💡 높은 호출 빈도가 예상되는 API: 피드 조회 API

• 각 사용자의 맛집 피드를 조회하는 getFeedListByUserId API를, 가장 높은 호출 빈도가 예상되는 API로 선정하였습니다.

• 사용자의 서비스 사용 주요 목적과 행동 패턴을 고려했을 때, 해당 API를 최적화하는 것이 중요할 것으로 판단됩니다.

💡 API 분석

1. 사용자 중심의 주요 기능

   • 핵심 역할
     피드 조회는 스푸니 서비스의 사용자 경험(UX)에서 가장 중요한 부분 중 하나입니다. 사용자가 애플리케이션에 방문하는 주요 이유는 자신과 관련된 정보(예: 게시물, 추천 피드)를 탐색하기 위함입니다.

   • 특화된 API
     getFeedListByUserId는 특정 사용자와 연관된 게시물 목록을 조회하며, 탐색 페이지의 주요 데이터 소스로 활용됩니다.

2. 반복적이고 지속적인 호출 가능성

   • 새로고침 빈도
     사용자는 새로운 게시물을 확인하기 위해 여러 번 데이터를 갱신하거나 새로고침할 가능성이 높습니다.

   • 무한 스크롤 패턴
     추후 서버와 클라이언트 모두 피드 조회 시 페이징을 적용할 계획이고, 무한 스크롤 기능을 사용하면 추가 데이터를 불러오기 위해 API 호출이 계속 발생할 수 있습니다.

3. 필터 및 정렬 조건

   • 위치 기반 필터(location_query)나 카테고리(categoryId) 선택, 정렬 기준(sortBy) 변경 등으로 인해 동적인 데이터 요청이 증가합니다.

   • 이러한 옵션은 사용자 맞춤형 피드를 제공하기 위한 필수 요소로, 호출 빈도를 높이는 주요 요인입니다.

---

💡 호출 상황 구체적 예시

• 앱 초기 실행
  사용자 로그인 후 탐색 화면에서 기본 피드 로드.

• 필터 조건 변경
  사용자가 위치 또는 카테고리 필터를 수정.

• 정렬 옵션 변경
  `최신순'과 '인기순' 간의 정렬 기준 변경.

• 무한 스크롤 사용
  사용자가 피드를 계속 탐색하며 추가 데이터를 요청.

---

💡 API 최적화 방안 향후 계획

1. API 호출 최적화

   • 페이징 처리
     적절한 페이지 크기 설정으로 데이터를 효율적으로 로드할 수 있습니다.

   • 캐싱 전략
     클라이언트 또는 서버에서 캐싱을 활용해 중복 호출을 줄일 수 있습니다.

2. DDD(Domain-Driven Design) 패턴을 사용한 API 분리

   • 현재 DDD 방식으로 설계되어 있는 아키텍처를 사용하여, 피드 조회 API를 독립된 서버로 트래픽을 분산시킬 수 있습니다.
   • Nginx를 사용하여 독립된 서버로 라우팅

---

▶️ 핵심 api 가 무엇일지?

💡 핵심 API: 사용자 지도 리스트 조회 API

• 게시물 등록, 피드 조회 등 여러 핵심 API가 존재하지만, 서비스의 목적과 가장 밀접하게 닿아있는 지도 리스트 조회 API를 핵심 API로 선정하였습니다.

• 해당 API를 통해 사용자는 본인이 등록한 장소를 지역별로 탐색할 수 있습니다. 사용자가 맛집을 하나씩 추가하고 열람하는 과정이 본 서비스의 가장 중요한 비즈니스 로직입니다.

---

▶️우리 서비스는 read 성 api 가 많은지, write 성 api 가 많은지?

💡READ 성 API

• 정의
  GET 메서드를 사용하는 데이터 조회 중심 API.

• 종류

  • 사용자 정보 조회 (GET /api/v1/user/{userId})
  • 장소 검색 (GET /api/v1/place/search)
  • 사용자 피드 조회 (GET /api/v1/feed/{userId}/{categoryId})
  • 게시물 조회 (GET /api/v1/post/{userId}/{postId})
  • 카테고리 조회 (GET /api/v1/post/categories)

• 분석

  • READ 성 API가 많으며, 서비스가 콘텐츠 탐색과 조회를 중심으로 설계되어 있음을 보여줍니다.
  • 사용자 피드와 게시물 탐색이 주요 기능이기 때문에, 데이터를 읽는 동작이 전체 사용 흐름에서 차지하는 비중이 매우 크다는 것을 알 수 있습니다.

💡WRITE 성 API

• 정의
  POST 및 DELETE 메서드를 사용하는 데이터 생성/수정 중심 API.

• 종류

  • 게시물 등록 (POST /api/v1/post)
  • 게시물 찜 추가 (POST /api/v1/post/zzim)
  • 찜 삭제 (DELETE /api/v1/post/zzim/{postId})
  • 게시물 신고 (POST /api/v1/report)
  • 게시물 스쿱 (POST /api/v1/post/scoop)

• 분석

  • WRITE 성 API는 상대적으로 적습니다.
  • WRITE 성 API는 주로 콘텐츠 생성 또는 사용자 행동(찜, 신고, 스쿱 등)을 기록하는 데 사용됩니다.
  • 이를 통해 서비스가 사용자 생성 콘텐츠(UGC)보다는 콘텐츠 소비 및 탐색에 초점을 맞추고 있음을 알 수 있습니다.