API設計 - Githubissues

shamisonn commented 4 years ago

具体が決まってないのでmtgもやる
RESTでもいいしrpcでもいい
- RESTでいいね。。
ui図 https://drive.google.com/file/d/1NWRm-PIzBgNPBOBcwp4WazugJFkZsbb9/view?usp=sharing

shamisonn commented 4 years ago

naoi217 commented 4 years ago

openapiを見て思ったこと

voicesやtagsについてはpagingを考慮しない方針？最初は登録数が少ないからpagingしないでいいかなと思うけど、今後多くなった時のことを考えると実装する必要はあるかと思う。

ちなみに、注文の例を共有しておくと APIではquery paramにlimitとpageを渡す。レスポンスとしては例えば、limit = 5, page = 1を渡した場合

"page" :  {
    "total": 10,
    "current": 0,
    "limit": 5,
    "has_previous": false,
    "has_next ": true,
}

みたいな感じで返してるよ。

フロント側で欲しいかなと思うエンドポイントとしてはタグだけの一覧を取得するエンドポイントはやっぱ欲しいかなって思った。今日のMTGでキャッシュがあればまあって言ってたのでパフォーマンス次第ではあるけども...。欲しいと思った理由としては2つ

フロントエンドしか知らない人の場合にはtagsって名前を見た時にタグのみの一覧を返すエンドポイントと間違えやすいかと思ったのでよりタグのみを返すエンドポイントとタグからvoiceを返すAPIなのか混乱しそう。
tagの数ってvoice x n って考えるとページングをしない場合、tagsのエンドポイントのキャッシュがない場合のコストがやばくなりそう。

tagsのエンドポイントのレスポンスについてこれはフロント側のわがままなのかもしれないけどtagが持ってるvoicesのカウントを入れて欲しいと思った。

shamisonn commented 3 years ago

issues

[ ] pagingを考慮したい
[ ] tagsだけのレスポンスをとりたいケースが有るので、そうしたい
- tag一覧、tagの入力補完とかを考えると必要
- 「tagだけのendpoint」と「tagsとvoice」のendpointが別れていると何も考えずにコーディングできて楽
- voiceに関してはtagと一緒に必ず表示されることが想定されるので、そのままで良さそう
[ ] tagsのレスポンスにvoiceのcountを入れたい

nayami

(1). tags/
- nestなし
(2). nestのやつ
- a.tags&attach_voice=1 :+1: これで！
- キャッシュとかできんのかな？
- attach_voiceはboolean
- いざかえる、ってなったときでも楽そう
- b.tags_w_voice/
- REST的にきもい
- c. tags/voice
- tags/$id/voiceの用途があるからごちゃる
- レスポンスをどの形式にするか、はきになる
voiceで別に分けるかどうか?
- voices/とvoices&attach_tags=1にわけたい
- => 分けよう！
- voices/（nestなし）が使われる機会が現状は見えない

unvavo commented 3 years ago

みなさんコメントありがとうございました！

3点対応しましたので再度レビューお願いします。

sakaba-project / sakaba