Open Yoshino-Yukitaro opened 4 months ago
必要そうなやつ(主観)
行き先のカテゴリと距離を設定して目的地を提案する 目的地の情報がレスポンス
GET /api/places/suggest
↓こんな感じのクエリで渡す
?category=サウナ&distance=near&lat=35.6789&lng=139.8765
行き先に到着したという情報の送信と報酬の受け渡しのAPI 髪型とかのアイテムと好感度の数値がレスポンス(好感度は反映後のもの)
POST /api/places/arrive
形式はJSON
{
"item": {
"id": 123456,
"category": "hairs",
"name": "エメラルドグリーンのツインテール",
"image_url": "https://sample.no.url.desu"
},
"rank": 5,
"until_next_rank": 10084,
"get_rank_point": 100
}
形式はJSON
{
"place_id": "asdfghjkl",
"distance": "near"
}
所持している靴や髪型の一覧が取得できるAPI(カテゴリごとに分ける)
部位ごとのアイテムidを指定して設定している服装を変更するAPI
PUT /api/beauty-girls/${id}/put-on
形式はJSON
{
"hair": {
"name": "エメラルドのツインテール",
"image_url": "https://hoge.image.no.url.desu"
},
"shoes": {
"name": "黒い靴",
"image_url": "https://hoge.image.no.url.desu"
},
"bottoms": {
"name": "ピンクのスカート",
"image_url": "https://hoge.image.no.url.desu"
},
"tops": {
"name": "甲冑",
"image_url": "https://hoge.image.no.url.desu"
},
}
形式はJSON
{
"items": [
{
"category": "bottoms",
"item_id": 123456
},
{
"category": "tops"
"item_id": 123456
}
]
}
@ryichk @madomaru @hirodesu85 @iineineno03k
皆さんのコメントを元に↑の表を埋めていこうと思うので、それぞれのAPIについて下記のフォーマットでアイデアを教えてください 🙏 (編集はご自由にどうぞ :pray: )
## API名
### URL
### レスポンス
### リクエスト
### なんかコメント
個人的には「目的地提案API」の方が名前としてしっくりくるかもです🤔 行くかどうか決定するのはチバニャンなので、このAPIは提案だけするというニュアンス
案
/api/places/suggest
/api/places/recommend
/api/places/random_suggest
POST or GET
?category=サウナ&distance=near&lat=35.6789&lng=139.8765
コントローラのイメージ
Api::PlacesController#suggest
レスポンスはJSON形式で大丈夫ですかね? 一回の提案で何箇所提案するんでしたったけ?一箇所だけでいいんでしたっけ?
{
"place_id": "ChIJw76RQYuMGGARHeYoDcNpsZQ",
"latitude": "",
"longitude": "",
}
このAPIを叩いた時に、提案した場所を一度訪れた場所として登録するか? それとも一度訪れた場所を登録するのは、行き先到着APIの方でするか?
↑早速ありがとうございます!!
取り急ぎタイトルを「目的地提案API」に修正しました!
案
- /api/places/suggest
- /api/places/recommend
- /api/places/random_suggest リクエスト POST or GET
この中なら個人的にはsuggest
が一番しっくりきます!
GETの場合はクエリパラメータ ?category=サウナ&distance=near&lat=35.6789&lng=139.8765 コントローラのイメージ
ここは同感です :+1:
Api::PlacesController#suggest
レスポンスはJSON形式で大丈夫ですかね? 一回の提案で何箇所提案するんでしたったけ?一箇所だけでいいんでしたっけ?
レスポンスはJSONの想定です! また提案する場所の個数は最初は複数で考えていたのですが、鈴木さんのデザインを見てからは1つでも良いかな?と思うようになりました(おそらくチバニャンは自分で行ったことがない場所を毎度検索するのが億劫 -> 複数提示されるのは好まないのでは?と思い直したため) ここは早めに全員の認識をそろえる必要がありますね 🤔 今日の定例で聞いてみます!
{
"place_id": "ChIJw76RQYuMGGARHeYoDcNpsZQ",
"latitude": "",
"longitude": "",
}
このAPIを叩いた時に、提案した場所を一度訪れた場所として登録するか? それとも一度訪れた場所を登録するのは、行き先到着APIの方でするか?
ゴールしなかった場合に訪れなかったことになると思ったため、行き先到着APIで良いと思っています!
📝 市来さんの意見を反映しました(確認が必要そうな場所は別途確認してからにします) 行き先到着APIについて草案を書きました
📝 市来さんの意見を反映しました(確認が必要そうな場所は別途確認してからにします) 行き先到着APIについて草案を書きました
ありがとうございます! :pray:
レスポンスはJSONの想定です! また提案する場所の個数は最初は複数で考えていたのですが、鈴木さんのデザインを見てからは1つでも良いかな?と思うようになりました(おそらくチバニャンは自分で行ったことがない場所を毎度検索するのが億劫 -> 複数提示されるのは好まないのでは?と思い直したため) ここは早めに全員の認識をそろえる必要がありますね 🤔 今日の定例で聞いてみます!
了解です! 今日話せてないかもですが、一旦1つで良いような気はしますね🤔
ゴールしなかった場合に訪れなかったことになると思ったため、行き先到着APIで良いと思っています!
提案された場所が過去に行ったことある場所で、行き先を変えたいケースとかはMVPのLv.1では考慮しなくて良いですかね🤔 つまり、一度提案された場所でも到着してなければ、別の機会に再度提案される可能性があるということですよね
URL
POST /api/places/arrive
良いと思います!
レスポンス
- item
- category(hairsとかshoesとか): string
- id: integer
- name: string
- image_url: string
- rank(好感度反映後の現在のランク): integer
- until_next_rank(次のランクアップまでの好感度): integer
良さげです! 好感度がいくつ上がったかも表示するのであれば、それも返した方が良いですかね? それか、固定値なのでクライアントで管理しても良いですかね 🤔
リクエスト
- place_id: string
形式はJSON
{ "place_id": "asdfghjkl" }
近い or 中間 or 遠い で上がる好感度の数値が違うので、distance
or 好感度の数値
もリクエストでもらった方が良いかもですね
提案された場所が過去に行ったことある場所で、行き先を変えたいケースとかはMVPのLv.1では考慮しなくて良いですかね🤔 つまり、一度提案された場所でも到着してなければ、別の機会に再度提案される可能性があるということですよね
これを提案された時点で何も聞かずに弾いてしまうのは危険だと考えており、実装するなら決定の時点で「ここにする!」「別の場所にする」みたいな選択肢の他に「ここは前に行った」みたいな選択肢を設ける必要があると思います 🤔 しかし、一旦はここまで考える必要はない気がしています。
URLについて:良いと思います!
:pray:
レスポンスについて:良さげです! 好感度がいくつ上がったかも表示するのであれば、それも返した方が良いですかね? それか、固定値なのでクライアントで管理しても良いですかね 🤔
返してあげたほうが親切な気がしたので追加します :pray:
リクエストについて:近い or 中間 or 遠い で上がる好感度の数値が違うので、distance or 好感度の数値もリクエストでもらった方が良いかもですね
確かにです!追加します 💦
📝 市来さんの意見を反映しました
これを提案された時点で何も聞かずに弾いてしまうのは危険だと考えており、実装するなら決定の時点で「ここにする!」「別の場所にする」みたいな選択肢の他に「ここは前に行った」みたいな選択肢を設ける必要があると思います 🤔 しかし、一旦はここまで考える必要はない気がしています。
そうですね!一旦大丈夫だと思います :pray:
市来さんの意見を反映しました
ありがとうございます!! :pray: 行き先到着APIも作れそうですね :ok_man:
行き先到着API, 目的地提案APIについては現在確定しているもので問題ないと思います!!
一点確認ですが、until_next_rankは到着時に受け取った好感度を加算した後の次のランクまでの好感度でしょうか?(以下の画像のような理解であってますか?now_rank_pointはスマホアプリ側で持っているとしてます)
行き先到着API, 目的地提案APIについては現在確定しているもので問題ないと思います!! 一点確認ですが、until_next_rankは到着時に受け取った好感度を加算した後の次のランクまでの好感度でしょうか?(以下の画像のような理解であってますか?now_rank_pointはスマホアプリ側で持っているとしてます)
@madomaru ありがとうございます! until_next_rankについてその認識で合っています! ちなみに現在のランクについてもrankというパラメータでバックエンドから返す認識です!
@ryichk なるほど、ありがとうございます! 私が書いた図のnow_rank_pointは、現在取得済みの好感度ポイントのイメージでした! こちらは今までのget_rank_pointを加算すればcliantでデータを持つことが可能なのですが、バックエンドとフロントエンドのどちらで持った方がいいですかね?
@madomaru なるほど!now_rank_pointは好感度バーの表示に必要な、現在ランクの累計好感度ポイントですね! バックエンドで管理する必要性もないと思うので、フロントエンドで管理可能であればフロントエンドで良いと思います! :pray:
📝 服を着るAPIの草案を追記しました
まだ確認できていなかった、Lv2のAPIについてコメントします!
無し
無し
カテゴリごとに分けてた状態で、それぞれのアイテムの Id, name, image_urlをお願いします。
また、もし鈴木さんのラフにある「入手順」などを実装するのであれば、sortするためのAPIもしくは、変数も追加して欲しいです!
服を着るAPI 2つ質問があります!
それ以外の部分については問題ないと思います。
@madomaru コメントありがとうございます!
カテゴリごとに分けてた状態で、それぞれのアイテムの Id, name, image_urlをお願いします。
id, name, image_urlの他に現在装備しているアイテムがわかるようにis_equippedという真偽値も返そうと考えています! また、1つのAPIで4種類のアイテムまとめて返すようにしようと考えているのですが、フロント的にアイテムのカテゴリ毎にAPIが分かれていた方が良かったりしますか?
考えているAPIの詳細:https://github.com/hirodesu85/GIFTech2024_backend/issues/16
また、もし鈴木さんのラフにある「入手順」などを実装するのであれば、sortするためのAPIもしくは、変数も追加して欲しいです!
sortのこと忘れてました!ありがとうございます! :pray:
sortするためのAPIを別で用意するというよりは、この一覧APIのリクエストでorder
のようなパラメータを送ってもらい、並び替えた状態で一覧を返すのが良いかなと思っています
それか、並び替えはバックエンドで行わず、入手日も一緒にレスポンスで返しておいて、フロントで並び替えてもらうという手もありな気がします(アイテムの数も多くないですし)
リクエストのitemsが複数形になっている & レスポンスが全カテゴリあるということは、複数カテゴリのアイテムを選択して一気に着替えることを想定していますか?
はい、複数カテゴリのアイテムをまとめて選択して着替えられることを想定しています! フロント的に厳しかったりしますか?
美少女の名前をこのタイミングで取得する意図はなんでしょうか?
必要性はないですよね🤔 @Yoshino-Yukitaro 何か意図ありましたか?
@madomaru @ryichk
美少女の名前をこのタイミングで取得する意図はなんでしょうか?
リソース的に含まれてるから返していただけなので、不要なのであれば削除して良いと思います!
@madomaru あと美少女の情報(今何をきているか、名前は何か、など)をいつどのAPIで返却するかは美少女の情報をクライアントでキャッシュ(端末側に保存)できるか次第ではあるのですが、美少女取得APIで得られた情報をキャッシュしておくことは可能ですか? 🤔
お二人ともご返信ありがとうございます!
@ryichk
フロント的にアイテムのカテゴリ毎にAPIが分かれていた方が良かったりしますか?
今回アイテムの数が多いわけではないので、1つのAPIでまとめて取得してもいいと思いました!タブ移動のたびに非同期処理が起こるよりもUXが良さそうな気がします。
sortについても非同期処理をはさまないように、フロント側で行います! 鈴木さんに入手順以外に何があるか聞いておきます!
@Yoshino-Yukitaro
あと美少女の情報(今何をきているか、名前は何か、など)をいつどのAPIで返却するかは美少女の情報をクライアントでキャッシュ(端末側に保存)できるか次第ではあるのですが、美少女取得APIで得られた情報をキャッシュしておくことは可能ですか?
可能です。UserDefaults(https://qiita.com/uhooi/items/429cac9b798b9c0937ae) を使って、アプリ内に永続化(アプリを閉じた後も保持)することができます。そのため、ランク、着ているもの、名前などが変更された時点で、UserDefaultsの値を変更すればいいため、美少女情報取得APIは要らないかもです!
@madomaru
今回アイテムの数が多いわけではないので、1つのAPIでまとめて取得してもいいと思いました!タブ移動のたびに非同期処理が起こるよりもUXが良さそうな気がします。
ありがとうございます! 1つのAPIでまとめて取得するようにします 🙆
sortについても非同期処理をはさまないように、フロント側で行います! 鈴木さんに入手順以外に何があるか聞いておきます!
ありがとうございます! 助かります :bow:
@madomaru
可能です。UserDefaults(https://qiita.com/uhooi/items/429cac9b798b9c0937ae) を使って、アプリ内に永続化(アプリを閉じた後も保持)することができます。そのため、ランク、着ているもの、名前などが変更された時点で、UserDefaultsの値を変更すればいいため、美少女情報取得APIは要らないかもです!
ありがとうございます!では、美少女情報の表示的な管理はアプリ側に一任させていただきます :pray:
📝
@Yoshino-Yukitaro 服を着るAPIについて質問です!(もうすでに実装を始めている所申し訳ないです!) アイテム選択画面を設計中にふと思ったのですが、今何を着ているかの情報をクライアント側で持っている仕様ならば、服を着るAPIは必要ないと思ったのですが、いかがでしょうか?
@madomaru うーん確かに 🤔 エンドポイントを消すのはちょっと面倒くさいので、使わない方向で実装進めちゃいましょうか 🙏
@ryichk ↑な感じなので、アイテム一覧APIで「今身につけているかどうか」を返す必要もなさそうです 💦
@madomaru
クライアント側で入手順ソートをしてもらうために、アイテム一覧APIでgained_at
(入手日時)をレスポンスしようと思うのですが、以下のようなデータで問題なくソートできそうでしょうか?
{
"hairs": [
{
"id": 1,
"name": "エメラルドのツインテール",
"image_url": "https://hoge.image.no.url.desu",
"gained_at": "2024-04-19T12:34:56Z"
},
{
"id" 2,
"name": "ルビーのツインテール",
"image_url": "https://hoge.image.no.url.desu",
"gained_at": "2024-04-20T12:34:56Z"
}
],
...
@Yoshino-Yukitaro
バックエンドの処理として、updated_at
の日時をgained_at
として返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔
@ryichk
バックエンドの処理として、updated_atの日時をgained_atとして返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔
問題ないと思います!
@ryichk
バックエンドの処理として、updated_atの日時をgained_atとして返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔
問題ないと思います!
ありがとうございます! 🙆♂️
@ryichk こちらのデータで大丈夫です!
@ryichk こちらのデータで大丈夫です!
@madomaru ありがとうございます! 🙆♂️
概要
固定値を返すだけのControllerを早めに作成したいです。理由はクライアントとの疎通や認識合わせを早めに済ませたいからです。
画面がおおよそわかってきたため、まずは必要そうなものの洗い出しを行いたいです。