APIの仕様書を作成した #5
APIの仕様書を作成した #5
Conversation
|
Swagger Editor で確認するのがおすすめです．
|
There was a problem hiding this comment.
以下気になった点
- Swagger UIでテスト実行できないんやけどこれまだデプロイ先でAPIサーバ構築してないからよね
- antherはGoogle Books APIだと配列だけど結合して文字列でいいのね
- 本にtagみたいなのを使うって話はどうなってる感じ？今の段階だと気にしなくていいんかな
- 本のサムネイルURLは使わないかな？なんか画像ないと味気なくない？
- 本の情報をUPDATEした時に返す値はOKではなくて、変更後の本の情報じゃね？
- UPDATE BOOKのとこで、渡す情報はBOOKのすべての情報をテストで渡してるけど、これ一部だけ渡すとどうなるの？一部の情報だけ送った時はその情報だけ更新されるって実装は難しいかな。難しいならフロントの方で配慮した設計にするけど。
- ↑BOOK以外のスキーマでも同様の疑問があります。
BOOKの検索APIについてテストでは本データ全部入れてるけどこれって全部必要？それだと検索は実質不可能では- キーワード検索みたいなやつって実装する予定ありますかね
- PAGE系のAPIはpage番号と各ページごとに何個表示するかみたいなクエリもいるくないか？
- なんかデータの更新系はOKを返すことが多いけど、変更後のスキーマを返す方が良くね？
- loanのPUT系のAPIでcreated_atとかupdate_atってあるけどこれフロントエンド側が現在自国の時間データ獲得するの？こういうのってバックエンド側では？
- loanのデータがcrteateされる時っていつ？初めてPUTが叩かれた時？もしそうならフロントは楽でありがたいわね。
- ユーザー名じゃなく、メールアドレスで管理するんやね。それならFIrebaseとか実装してみた方が良いかね。
コメントと質問が混ざってるけど、一応全部確認してください。
ただ、いくつかの質問は実際のAPI実装時にはっきりしそうですね。ただ共通認識は欲しいので。
ひとまずコメント確認した上で問題なさそうならmergeしてOKです！！
そうです |
文字列の結合をフロントとバックどっちでやるかによって変わってくる。配列にしておいた方がフロントの実装に柔軟性を持たせることができるので、配列で返すように変更しよう。 |
タグを付けるとなると考えることが増えるので、後からでもいいかなと思っている。まずは最低限の機能でリリースまで持っていきたい。 |
確かに画像あった方が見栄えがいいね。本を取得するAPIにURLを追加しよう。 |
変更後にリダイレクトする画面で変更後の本の情報が必要なら、本の情報を返す必要があると思う。必要ないならOKでもいいと思う． 更新後のリダイレクト先がまだ決まっていなかったので，話し合いたい． |
一部だけ渡された場合は、その属性だけ更新する仕様で考えている |
タイトルとか著者とか関係なくキーワードだけで簡易検索できる機能だと理解した． 結論は今のところ考えていない．実装するなら，簡易検索と詳細検索で画面を分ける必要があると思っていて，いち早くリリースするためにまずは詳細画面だけ実装する方針で考えている． |
そこはバックエンドで固定値にしようと思ってたけど、柔軟性を持たせるために指定できるようにしよう。 |
パラメータから消しておく |
PUTしか用意しない場合は新規作成と更新をどうやって区別するか？が問題となる．貸借のAPIはもう一度考え直す必要がありそう． |
「Firebaseとか実装してみる」の意味を理解できなかった．Firebaseを使うのが良さそうというアドバイス？ |
これはただのメモでしたわ。あんま気にしないで。 |
|
追加で気になったこと
現在ログインしているかどうかは，Cookieの値で確認できるようにするつもり．APIを用意するつもりはない． スレッド機能が使えないのでここに返信した．次回からはスレッド機能が使える 行コメント を使っていこう． |
Close #4
/books/users/loans