Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/target/{targetId}/pick 데이터 형태 및 API 문의 #98

Open
blcklamb opened this issue Aug 7, 2023 · 0 comments
Open

/target/{targetId}/pick 데이터 형태 및 API 문의 #98

blcklamb opened this issue Aug 7, 2023 · 0 comments
Assignees
Labels

Comments

@blcklamb
Copy link
Contributor

blcklamb commented Aug 7, 2023

주제

/target/{targetId}/pick API 관련 질문
관련 링크

1. Restful한가요?

해당 씬은 받는 사람이 최종 상품을 1개 선택하는 것이고, 이후 /target/{targetId}/final에 의해 조회되는 데이터를 업데이트하는 걸로 이해하고 있는데, 과연 GET 요청이 적합한지 모르겠습니다.

저는 다음 씬을 고려하지 않고 해당 API만 봤을 때 조회가 아니라 결과를 반영하는 것이라서 POST가 더 맞는 것 같은데, 혹시 GET으로 구성한 이유가 별도로 있을까요?

우선 GET으로 작업하고 API 작동 여부는 확인했습니다.

2. request query 유일성 보장

지금은 giftId로 보내고 있는데 couponId를 집어 넣어도 결과는 업데이트가 잘 되는 상황입니다.
혹시나 데이터를 쌓는 부분에서 giftIdcouponId가 겹칠 일은 없는 건가요?
그렇게 되면 프론트 쪽에서 로직을 리펙토링할 수 있을 것 같아서 물어봅니다.

3. giftId 네이밍

그리고 현재 상품 - 선물이 혼동되는 것 같아서 네이밍 통일이 필요한 것 같습니다.

선물 > 상품 또는 쿠폰

이 범위를 가지고 있는데 giftId가 여기 request query 이름으로 넣기에는 쿠폰을 포함하지 않아서 적합하지 않은 것 같습니다.

명확히 하려면 선물(gift) > 상품(product) 또는 쿠폰(coupon) 이렇게 정하는 게 최선일 것 같습니다.
그런데 확인해 보니 현재 상품에 해당되는 것들이 전부 gift로 되어 있어서
상품과 쿠폰을 묶어서 부르는 다른 네이밍(ex. resultId, finalId)로 변경하는 게 공수가 최소한으로 될 것 같은데,
이렇게 변경하는 건 어떠신가요?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants