2020-NAVER-CAMPUS-HACKDAY/Influencer

상품구성 관련 API Spec 질문

Closed this issue · 6 comments

> 실제 데이터와 유사한 정보, 요청하시는 Spec 에 맞춰 구현해드리며 데이터 Interface는 사전에 공유.

- 제공가능한 API 기능은 다음과 같다. (요구에 의해서 API 설계후 제공)
 - 추천을 위한 데이터 수집을 위한 무작위 상품 데이터 정보
 - 수집된 추천데이터에 맞는 상품의 상품 데이터 정보



멘토님께서 #4 시나리오 이슈에서 위와 같은 언급을 하셨었는데요.
제가 좀 헷갈려서 정리좀 하고자 이슈 등록합니다!
일단 제가 이해한 걸 적어보겠습니다!



1. 추천을 위한 데이터 수집을 위한 무작위 상품 데이터 정보

이건 사용자가 인터렉션을 할 때 필요한 상품들을 받아오는 API로 이해했는데 맞나요?

2. 수집된 추천데이터에 맞는 상품의 상품 데이터 정보

이 부분은 이해하기에 두 가지 케이스가 있는 것 같습니다. 뭐가 맞나요?

Case 1. 사용자의 인터렉션을 통해 선호, 비선호 상품들을 수집했으면,
이제 그 데이터를 가지고 그 데이터에 맞는 추천 상품들을 받아오는 API
(즉, 추천을 하기 위한 알고리즘이나 ML 과정이 필요없음.)

Case 2. 사용자의 인터렉션을 통해 선호, 비선호 상품들을 수집한 후
그 데이터를 가지고 서버에서 추천 상품을 필터링해서,
그 필터링된 상품 각각의 데이터를 받아오는 API

일단 제가 이해한 대로 적어봤습니다. 피드백 부탁드리겠습니다! :)

@minsour

1. 추천을 위한 데이터 수집을 위한 무작위 상품 데이터 정보

  • 네, 이해하신 게 맞습니다.

2. 추천을 위한 데이터 수집을 위한 무작위 상품 데이터 정보

  • 두 가지 케이스 모두 가능한 거 같은데요. 생각은 2번에 좀 더 가까운 거 같아요. 결국 인터럭션을 통해서 선택된 상품의 데이터셋의 정보들을 통해서 그 값으로 호출하는..
  • 예를 들어 통신하는 api의 request 에 공통되는 아이디, 혹은 속성 등등 요청하는 방식으로 제공할 수 있을 꺼 같아요.

중요

다만, 상품을 제공하려는 API 에 대해서 현재 원래의 계획과 조금의 변수가 생겼는데요. ㅠ_ㅠ
요 부분은 확실해지면 다시 별도의 이슈를 통해서 빠르게 고지 하도록 하겠습니다. (5월 8일 한..)

이슈가 해결되냐 안되냐에 따라..
제가 제공을 못하게 되면 별도로 inteface 를 지정해서 거짓 상품을 밀어넣고 테스트 하는 방향이나 openApi 또한 고민해야할 것 같아요 ㅠㅠ

@withearth

1번은 제가 이해한 게 맞고,

2번은 사용자의 인터럭션을 통해 수집된 데이터 셋을 가지고
어떤 상품들을 추천해 줄 지 적절한 추천 알고리즘을 통해 서버에서 결정한 후,
추천해주기로 결정된 각각의 상품 아이디를 가지고 상품 데이터를 가져오는 데 사용할 api로 이해했는데 맞나요??

이슈가 해결되냐 안되냐에 따라..
제가 제공을 못하게 되면 별도로 inteface 를 지정해서 거짓 상품을 밀어넣고 테스트 하는 방향이나 openApi 또한 고민해야할 것 같아요 ㅠㅠ

그리고 이 부분은 핵데이동안만 사용할 상품 더미 데이터를 제공해 주실 수 있으시면
외부 api 호출 없이 그냥 더미 데이터 형식에 맞춰서 mongodb document 만들어서 넣어놓고 사용해도 될 것 같은데 어떻게 생각하시나용?

어떤 상품들을 추천해 줄 지 적절한 추천 알고리즘을 통해 서버에서 결정한 후,
추천해주기로 결정된 각각의 상품 아이디를 가지고 상품 데이터를 가져오는 데 사용할 api로 이해했는데 맞나요??

  • 특정 상품 아이디로만 가져오는 것보다는 제 생각에는 추천 받을 상품들의 여러가지 구분값 (e.g. 카테고리, 속성 등등) 을 통해서 해당 리스트를 구현하는 게 좋을 것 같습니다.

외부 api 호출 없이 그냥 더미 데이터 형식에 맞춰서 mongodb document 만들어서 넣어놓고 사용해도 될 것 같은데 어떻게 생각하시나용?

  • 현재 상황에 따라 제공을 못해드리면 그것 또한 방법이 될 수 있을 것 같습니다. 👍

@withearth

특정 상품 아이디로만 가져오는 것보다는 제 생각에는 추천 받을 상품들의 여러가지 구분값 (e.g. 카테고리, 속성 등등) 을 통해서 해당 리스트를 구현하는 게 좋을 것 같습니다.

이 말이 제가 이해하기에는 Case2보다 Case1에 더 가까운 것 같아서 고민하다 다시 질문 남깁니다!
제가 질문은 애매하게 한 것 같아서 그림으로 시각화해서 다시 질문 드리겠습니다!

다시 보니까 제가 서버라는 말을 썼는데,
멘토님께서 제공해주시는 상품 api를 위한 서버와 저희가 프로젝트를 하면서 구현할 서버가 혼동되는 것 같네요. 😂

2번에서 제가 언급한 Case 2개의 주요 차이점은
추천 알고리즘이 멘토님께서 제공해주시는 상품 api를 위한 서버에서 실행되는가(Case1)
추천 알고리즘을 멘티들이 직접 구현하여 프로젝트의 Node.js 서버에서 실행하는가(Case2) 였습니다.

image

image

어떤 방향을 생각하고 계신 건가요? 죄송하지만 피드백 한 번 더 부탁드리겠습니다!

궁금증이 해결되어서 이슈 닫겠습니다.