hirodesu85 / GIFTech2024_backend

0 stars 0 forks source link

Controllerの作成 #4

Open Yoshino-Yukitaro opened 4 months ago

Yoshino-Yukitaro commented 4 months ago

概要

固定値を返すだけのControllerを早めに作成したいです。理由はクライアントとの疎通や認識合わせを早めに済ませたいからです。

画面がおおよそわかってきたため、まずは必要そうなものの洗い出しを行いたいです。

Yoshino-Yukitaro commented 4 months ago

必要そうなやつ(主観)

行き先決定API 目的地提案API

行き先のカテゴリと距離を設定して目的地を提案する 目的地の情報がレスポンス

URL

GET /api/places/suggest

レスポンス

↓こんな感じのクエリで渡す ?category=サウナ&distance=near&lat=35.6789&lng=139.8765

行き先到着API

行き先に到着したという情報の送信と報酬の受け渡しのAPI 髪型とかのアイテムと好感度の数値がレスポンス(好感度は反映後のもの)

URL

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

所持している靴や髪型の一覧が取得できるAPI(カテゴリごとに分ける)

URL

レスポンス

リクエスト

服を着るAPI

部位ごとのアイテムidを指定して設定している服装を変更するAPI

URL

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
    }
  ]
}
Yoshino-Yukitaro commented 4 months ago

@ryichk @madomaru @hirodesu85 @iineineno03k

皆さんのコメントを元に↑の表を埋めていこうと思うので、それぞれのAPIについて下記のフォーマットでアイデアを教えてください 🙏 (編集はご自由にどうぞ :pray: )


## API名

### URL

### レスポンス

### リクエスト

### なんかコメント
ryichk commented 4 months ago

行き先決定API

個人的には「目的地提案API」の方が名前としてしっくりくるかもです🤔 行くかどうか決定するのはチバニャンなので、このAPIは提案だけするというニュアンス

URL

リクエスト

POST or GET

コントローラのイメージ

レスポンス

レスポンスはJSON形式で大丈夫ですかね? 一回の提案で何箇所提案するんでしたったけ?一箇所だけでいいんでしたっけ?

{
  "place_id": "ChIJw76RQYuMGGARHeYoDcNpsZQ",
  "latitude": "",
  "longitude": "",
}

その他確認したいこと

このAPIを叩いた時に、提案した場所を一度訪れた場所として登録するか? それとも一度訪れた場所を登録するのは、行き先到着APIの方でするか?

Yoshino-Yukitaro commented 4 months ago

↑早速ありがとうございます!!

取り急ぎタイトルを「目的地提案API」に修正しました!

目的地提案API

URL

  • /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で良いと思っています!

Yoshino-Yukitaro commented 4 months ago

📝 市来さんの意見を反映しました(確認が必要そうな場所は別途確認してからにします) 行き先到着APIについて草案を書きました

ryichk commented 4 months ago

📝 市来さんの意見を反映しました(確認が必要そうな場所は別途確認してからにします) 行き先到着APIについて草案を書きました

ありがとうございます! :pray:

レスポンスはJSONの想定です! また提案する場所の個数は最初は複数で考えていたのですが、鈴木さんのデザインを見てからは1つでも良いかな?と思うようになりました(おそらくチバニャンは自分で行ったことがない場所を毎度検索するのが億劫 -> 複数提示されるのは好まないのでは?と思い直したため) ここは早めに全員の認識をそろえる必要がありますね 🤔 今日の定例で聞いてみます!

了解です! 今日話せてないかもですが、一旦1つで良いような気はしますね🤔

ゴールしなかった場合に訪れなかったことになると思ったため、行き先到着APIで良いと思っています!

提案された場所が過去に行ったことある場所で、行き先を変えたいケースとかはMVPのLv.1では考慮しなくて良いですかね🤔 つまり、一度提案された場所でも到着してなければ、別の機会に再度提案される可能性があるということですよね

ryichk commented 4 months ago

行き先到着APIについて

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 好感度の数値もリクエストでもらった方が良いかもですね

Yoshino-Yukitaro commented 4 months ago

提案された場所が過去に行ったことある場所で、行き先を変えたいケースとかはMVPのLv.1では考慮しなくて良いですかね🤔 つまり、一度提案された場所でも到着してなければ、別の機会に再度提案される可能性があるということですよね

これを提案された時点で何も聞かずに弾いてしまうのは危険だと考えており、実装するなら決定の時点で「ここにする!」「別の場所にする」みたいな選択肢の他に「ここは前に行った」みたいな選択肢を設ける必要があると思います 🤔 しかし、一旦はここまで考える必要はない気がしています。

URLについて:良いと思います!

:pray:

レスポンスについて:良さげです! 好感度がいくつ上がったかも表示するのであれば、それも返した方が良いですかね? それか、固定値なのでクライアントで管理しても良いですかね 🤔

返してあげたほうが親切な気がしたので追加します :pray:

リクエストについて:近い or 中間 or 遠い で上がる好感度の数値が違うので、distance or 好感度の数値もリクエストでもらった方が良いかもですね

確かにです!追加します 💦

Yoshino-Yukitaro commented 4 months ago

📝 市来さんの意見を反映しました

ryichk commented 4 months ago

これを提案された時点で何も聞かずに弾いてしまうのは危険だと考えており、実装するなら決定の時点で「ここにする!」「別の場所にする」みたいな選択肢の他に「ここは前に行った」みたいな選択肢を設ける必要があると思います 🤔 しかし、一旦はここまで考える必要はない気がしています。

そうですね!一旦大丈夫だと思います :pray:

市来さんの意見を反映しました

ありがとうございます!! :pray: 行き先到着APIも作れそうですね :ok_man:

madomaru commented 4 months ago

行き先到着API, 目的地提案APIについては現在確定しているもので問題ないと思います!! 一点確認ですが、until_next_rankは到着時に受け取った好感度を加算した後の次のランクまでの好感度でしょうか?(以下の画像のような理解であってますか?now_rank_pointはスマホアプリ側で持っているとしてます) image

ryichk commented 4 months ago

行き先到着API, 目的地提案APIについては現在確定しているもので問題ないと思います!! 一点確認ですが、until_next_rankは到着時に受け取った好感度を加算した後の次のランクまでの好感度でしょうか?(以下の画像のような理解であってますか?now_rank_pointはスマホアプリ側で持っているとしてます) image

@madomaru ありがとうございます! until_next_rankについてその認識で合っています! ちなみに現在のランクについてもrankというパラメータでバックエンドから返す認識です!

madomaru commented 4 months ago

@ryichk なるほど、ありがとうございます! 私が書いた図のnow_rank_pointは、現在取得済みの好感度ポイントのイメージでした! こちらは今までのget_rank_pointを加算すればcliantでデータを持つことが可能なのですが、バックエンドとフロントエンドのどちらで持った方がいいですかね?

ryichk commented 4 months ago

@madomaru なるほど!now_rank_pointは好感度バーの表示に必要な、現在ランクの累計好感度ポイントですね! バックエンドで管理する必要性もないと思うので、フロントエンドで管理可能であればフロントエンドで良いと思います! :pray:

Yoshino-Yukitaro commented 4 months ago

📝 服を着るAPIの草案を追記しました

madomaru commented 4 months ago

まだ確認できていなかった、Lv2のAPIについてコメントします!

美少女情報取得API

リクエスト

無し

レスポンスは

〇〇一覧API

リクエスト

無し

レスポンス

カテゴリごとに分けてた状態で、それぞれのアイテムの Id, name, image_urlをお願いします。

また、もし鈴木さんのラフにある「入手順」などを実装するのであれば、sortするためのAPIもしくは、変数も追加して欲しいです!

服を着るAPI 2つ質問があります!


  1. リクエストのitemsが複数形になっている & レスポンスが全カテゴリあるということは、複数カテゴリのアイテムを選択して一気に着替えることを想定していますか?
  2. 美少女の名前をこのタイミングで取得する意図はなんでしょうか?

それ以外の部分については問題ないと思います。

ryichk commented 4 months ago

@madomaru コメントありがとうございます!

〇〇一覧API

カテゴリごとに分けてた状態で、それぞれのアイテムの 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のようなパラメータを送ってもらい、並び替えた状態で一覧を返すのが良いかなと思っています それか、並び替えはバックエンドで行わず、入手日も一緒にレスポンスで返しておいて、フロントで並び替えてもらうという手もありな気がします(アイテムの数も多くないですし)

服を着るAPI

リクエストのitemsが複数形になっている & レスポンスが全カテゴリあるということは、複数カテゴリのアイテムを選択して一気に着替えることを想定していますか?

はい、複数カテゴリのアイテムをまとめて選択して着替えられることを想定しています! フロント的に厳しかったりしますか?

美少女の名前をこのタイミングで取得する意図はなんでしょうか?

必要性はないですよね🤔 @Yoshino-Yukitaro 何か意図ありましたか?

Yoshino-Yukitaro commented 4 months ago

@madomaru @ryichk

美少女の名前をこのタイミングで取得する意図はなんでしょうか?

リソース的に含まれてるから返していただけなので、不要なのであれば削除して良いと思います!

Yoshino-Yukitaro commented 4 months ago

@madomaru あと美少女の情報(今何をきているか、名前は何か、など)をいつどのAPIで返却するかは美少女の情報をクライアントでキャッシュ(端末側に保存)できるか次第ではあるのですが、美少女取得APIで得られた情報をキャッシュしておくことは可能ですか? 🤔

madomaru commented 4 months ago

お二人ともご返信ありがとうございます!

@ryichk

フロント的にアイテムのカテゴリ毎にAPIが分かれていた方が良かったりしますか?

今回アイテムの数が多いわけではないので、1つのAPIでまとめて取得してもいいと思いました!タブ移動のたびに非同期処理が起こるよりもUXが良さそうな気がします。

sortについても非同期処理をはさまないように、フロント側で行います! 鈴木さんに入手順以外に何があるか聞いておきます!

@Yoshino-Yukitaro

あと美少女の情報(今何をきているか、名前は何か、など)をいつどのAPIで返却するかは美少女の情報をクライアントでキャッシュ(端末側に保存)できるか次第ではあるのですが、美少女取得APIで得られた情報をキャッシュしておくことは可能ですか?

可能です。UserDefaults(https://qiita.com/uhooi/items/429cac9b798b9c0937ae) を使って、アプリ内に永続化(アプリを閉じた後も保持)することができます。そのため、ランク、着ているもの、名前などが変更された時点で、UserDefaultsの値を変更すればいいため、美少女情報取得APIは要らないかもです!

ryichk commented 4 months ago

@madomaru

今回アイテムの数が多いわけではないので、1つのAPIでまとめて取得してもいいと思いました!タブ移動のたびに非同期処理が起こるよりもUXが良さそうな気がします。

ありがとうございます! 1つのAPIでまとめて取得するようにします 🙆

sortについても非同期処理をはさまないように、フロント側で行います! 鈴木さんに入手順以外に何があるか聞いておきます!

ありがとうございます! 助かります :bow:

Yoshino-Yukitaro commented 4 months ago

@madomaru

可能です。UserDefaults(https://qiita.com/uhooi/items/429cac9b798b9c0937ae) を使って、アプリ内に永続化(アプリを閉じた後も保持)することができます。そのため、ランク、着ているもの、名前などが変更された時点で、UserDefaultsの値を変更すればいいため、美少女情報取得APIは要らないかもです!

ありがとうございます!では、美少女情報の表示的な管理はアプリ側に一任させていただきます :pray:

Yoshino-Yukitaro commented 4 months ago

📝

madomaru commented 4 months ago

@Yoshino-Yukitaro 服を着るAPIについて質問です!(もうすでに実装を始めている所申し訳ないです!) アイテム選択画面を設計中にふと思ったのですが、今何を着ているかの情報をクライアント側で持っている仕様ならば、服を着るAPIは必要ないと思ったのですが、いかがでしょうか?

Yoshino-Yukitaro commented 4 months ago

@madomaru うーん確かに 🤔 エンドポイントを消すのはちょっと面倒くさいので、使わない方向で実装進めちゃいましょうか 🙏

@ryichk ↑な感じなので、アイテム一覧APIで「今身につけているかどうか」を返す必要もなさそうです 💦

ryichk commented 4 months ago

@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として返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔

Yoshino-Yukitaro commented 4 months ago

@ryichk

バックエンドの処理として、updated_atの日時をgained_atとして返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔

問題ないと思います!

ryichk commented 4 months ago

@ryichk

バックエンドの処理として、updated_atの日時をgained_atとして返そうと思っているのですが、今のところ問題ないですよね..? 更新されるのはアイテム獲得時だけだと思うので新しいカラムを追加しなくても良いと思っています🤔

問題ないと思います!

ありがとうございます! 🙆‍♂️

madomaru commented 4 months ago

@ryichk こちらのデータで大丈夫です!

ryichk commented 4 months ago

@ryichk こちらのデータで大丈夫です!

@madomaru ありがとうございます! 🙆‍♂️