Closed equal-l2 closed 3 years ago
その形自体は綺麗だと思うんですが、現状だとそれはちょっと難しいです。
なぜかというと、フロントエンドのプロクシは/v1/
がベースパスになっているので、バックエンドの/
にはアクセスできないためです。
ただ、バージョンだけのためにエンドポイントが生えてるのも変と言えば変な気はしますね……
将来的な拡張を考えてサーバの情報のオブジェクトを返すようなエンドポイント(info
とか)を生やした方がいいのかな……
あ…プロクシ忘れてました.ではこのPRの通りでいいです
infoありですね
バックエンド側で/v1
にexactly matchedしたリクエストが来た時に/
にリダイレクトするようにしておき,フロントエンドでメタ情報がほしい時はaxios.get('/')
とすれば/
にまとめる作戦もできるのではないかということを思いつきました.ゴリ押しですけど
どちらにするかはデザインの問題なので、そちらで決定してくれればそれに従います。
@equal-l2
/から返すJSONに1つプロパティを生やせば十分ではないかと思います.
を実現したいです.
バックエンドの方を
// 62行目
app.get('/v1', (_req, res) => {
res.json({
message: 'This is backend server.',
version: VERSION // 何とかしてセットしておく
})
})
// 現在の/の挙動を変えたくない場合は気持ち悪いかもしれないが正規表現を使って/と/v1で同じのを返すようにすればよい app.get(/\/|\/v1/, (_req, res) => {
このように改修した上で,フロントエンドがバックエンドの`/^\/v1$/`にアクセスしてくれれば上記のJSONが返ります.
このやり方についてご意見があればお願いします.
一旦これで手元で実装してみます
続きは #90 で。
自分がバックエンドのバージョンとAPIのバージョンは同期してないとまずいと思い込んでいたので今まで言わなかったのですが,同期してなくていいなら
/
から返すJSONに1つプロパティを生やせば十分ではないかと思います./
から現在返しているというJSONに
version
を追加してに変えるということです.いいところとすると,ファイルが増えない,DBにアクセスしないcontrollerやrouterが必要なくなる,です.(それに関連して)また,バージョンはリソースではないですから他のルーターと同列に並んでいるのは少し不自然な感じがします.これも
/
から返すJSONに1つプロパティを生やせば十分ではないかと思う理由の一つです.これも言っていなかったので申し訳なかったのですが,APIサーバーの
/
はサーバー自身のメタ情報を返してくれると嬉しいと思っていました.個人的には/
にアクセスしてバージョン情報が返ってくるのは自然な挙動です.ただし客観的に見て,もしも
/
にアクセスして返ってくるversion
という情報がAPIのそれに見えてしまうようであれば混乱のもとなのでこの主張は取り下げます(書いていてちょっとそんな気もしてきてしまった).