Closed h-takeyeah closed 3 years ago
こういうJSONですね(キャメルケースに直しました)
{
"page": 3,
"nextPage": 4
"prevPage": 2,
"totalPage": 10,
"data": [
// データ
]
}
page
は、このオブジェクトだけポンと渡されたときに「このオブジェクトの次のページが見たいな」というような状況で使えそうなのであってよさそう。
nextPage
とprevPage
についてはまだ必要性を見出せていないので、具体例あったら教えてください。
細かいですがdataはobjectではなくobjectのarrayになります.つまり
"data": {
// データ
}
ではなくて
"data": [
// データ
]
だと思います.
確かにその通りでした。修正します。
@equal-l2 本APIではスネークケースで送信または応答されるので、そこはスネークケースに統一したほうが良いと思います。
@Stroheim001 確かにデータを受け取る他のエンドポイント(現状/room
のみ)ではスネークケースになってますね。
ただ、この辺の命名規則については気にしたことがなかったと思うので、このタイミングでどちらかに定めてドキュメントに書いた方がよさそうです。
/room
がuser_id
というsnake_caseのプロパティを取るのは、「Pythonの変数名がsnake_caseなのでそちらと合わせた」だけでした。
統一するなら、AMSの大半がTypeScriptで書かれている現状を鑑みて、camelCaseに統一するのがいいと思っています。
@equal-l2 InnoDBを使う以上,SQLのテーブル名およびカラム名において大文字小文字の区別ができないという「仕様」の壁があります(少なくともデフォルトでは→Identifier Case-sensitivity).その関係でDBからbackendが受け取るデータはスネークケースに従った形になっています.backendのコードはTSなのでキャメルケースにしていますが,backendからfrontendに渡すデータはスネークケースです.これは特別何か処理しているわけではなく,DBから受け取ったものをそのままfrontendに流しているだけです.やろうとすればキャメルケースに変換できるかもしれませんが,そうする積極的な理由はないでしょう.この点は同意いただけると思います.
ページネーションに必要な(DBのデータ以外の)情報,例えば今何ページ目か?など,はDBの仕様に依存するものではないので我々の裁量次第ですよね.とすれば自分としては何かに拠るのが良いと思います.そこでGoogle Cloud APIのAPI設計ガイドに拠るのを提案します.ここではフィールド名はスネークケースで,とあります.
標準フィールド | Cloud API | Google Cloud
いかがでしょうか.
https://github.com/su-its/ams-backend-nodejs/issues/23#issuecomment-791897338
というコメントを書きつつ,実験してみたらキャメルケースがMariaDBでも使えました.本当に決めれば決まるというかどちらでもいいという感じになりました.何かしらのORMを使用していればもう少しプラクティスもあったのでしょうか…….
@equal-l2 @h-takeyeah う~んと、一応APIが最初に書かれてたreadmeをそのままOpenAPIに起こした時にはスネークケースで書かれてるんですね、入力も出力も。 なので、そこを変えるというなら、まずdocsから変えて皆の中で認識の齟齬がないようにするべきではないかと思います。
@Stroheim001 @equal-l2 自分はDBから入力されてくるデータ,およびfrontendに出力するデータのプロパティはスネークケースで統一するのがいいと思います.単純に仕様変更が煩わしいという理由もありますが,長いものに巻かれたいというのもあります.Googleはよく知らないですが,twitterAPIは返り値のJSONがスネークケースです.そんな理由でスネークケースを推薦します.
自分がキャメルケースを推すのは、TSで外部入力をJSONからパースして使うときに、スネークケースのプロパティが混ざると見栄えが悪いという美的な理由です。 なので、技術上や相互運用上の問題があるのであればそこまで強固に主張したいというものではないです。
ページネーションを実装する.まだdataをただ返すだけなのでページネーションに必要な情報をくっつけて返すように変更します.
現時点ではこんな感じのJSONを返すようにしようかなと思っています.