[카페인] 리뷰 등록 flow - api 재설계하기

리뷰 등록 가능 여부, 스티커 발급 가능 여부 조회 api 설계

기존 방식의 경우 사용자는 리뷰를 모두 작성한 후 등록 버튼을 누르고 나서야 등록이 불가능하다는 응답을 얻을 수 있었다. 사용자는 이러한 수고로움을 겪어야 했고 이 문제를 해결하기 위해 리뷰 등록 화면 진입 전에 사용자에게 리뷰등록이 가능한지 알려주는 모달창을 띄어주도록 개선하기로 했다.

 

일단 리뷰 등록까지 Flow을 정리해보기로 했다.

<리뷰 등록 Flow 정리>

 

<리뷰 등록 예외 케이스 정리>

리뷰 등록 api 호출 시 등록할 수 없거나 스티커 발급이 불가능한 4가지의 예외 케이스가 존재한다.

1. 하루에 최대 3개 스티커 발급 제한
2. 최대 20개 스티커 보유 개수 제한
3. 신고로 인한 활동 정지 상태의 회원
4. 카페당 하루에 한번만 리뷰 작성 가능

 

평소 api당 한개의 기능만을 담당할 수 있도록 api를 쪼개어 설계하는 것을 선호 하지만 위 예외케이스 별로 api를 설계할 경우 리뷰 등록 플로우에 필요한 api 호출 횟수가 필요 이상으로 많다고 느꼈다. (리뷰 등록 api + 예외 케이스를 확인하는 api 4개)

기존 리뷰등록 api + 위 4개의 예외 케이스 개수만큼 api를 호출하는 것은 네트워크 통신이 빈번하여 성능상 좋지 않으며 리뷰 등록 시 예외 케이스가 추가될 경우 호출 횟수는 계속 늘어날 것이다.

 

<해결 방법>

프론트 서버와 백 서버의 통신을 줄이면서 기능에 집중한 api 설계를 위해

1. 리뷰 등록 가능 여부 api
2. 스티커 발급 가능 여부 조회 api

예외 케이스를 두 개로 통합하는 방식으로 설계하기로 결정했다. 단순히 모든 예외 케이스를 하나의 api에서 체크하는 방식을 선택할 수 있었지만 혼잡도, 카페 등록에도 스티커 발급 가능 여부 api가 필요했기 때문에 api 재활용이 가능하도록 스티커 발급 가능 여부 api는 따로 만들어 api 설계했다.

 

예외 케이스별로 다른 모달창의 띄어주기 때문에 프론트에서 이를 구분할 수 있도록 응답 값에 reason 필드를 추가해주었다.

 

예시)  활동 정지 상태인 회원의 경우

-Response Body

{
    "message": "리뷰 등록 가능 여부 조회 성공",
    "data": {
        "isPossibleRegistration": false,
        "reason": "활동이 정지된 회원입니다."
    },
    "code": 1
}

- 활동 정지 상태의 회원이 리뷰 등록 화면으로 이동 버튼을 눌렀을 경우 모달창

 

<리뷰 등록에 필요한 API 설계 정리>

1. 리뷰 등록 API
2. 스티커 발급 가능 여부 API
3. 리뷰 등록 가능 여부 API

리뷰 등록 완료까지 총 3번의 api를 호출하도록 호출 횟수를 줄였고 사용자가 리뷰를 작성하기 전, 리뷰를 등록할 수 있는지와 리뷰 등록으로 인한 스티커를 발급받을 수 있는지의 여부를 알 수 있도록 사용성을 개선하였다.