不要なAPIの削除

[xkumiyu]

データベースに入っている全ユーザ情報を返すAPI(http://localhost:3000/api/v1/users)
データベースに入っている全ルーム情報を返すAPI(http://localhost:3000/api/v1/rooms)

すぐに実装する必要はないけど、上記APIは不要なので削除したがいいと思う。 デバッグ目的ならCLIでお願いします。

$ rails c
pry(main)> User.all
pry(main)> Room.all

[hirokoji]

くみちょうが正しいです。 セキュリティ的にもあったらダメだし、正直いらないです。

ただ、、、暇だし、、、 それらのAPIを使って、各部屋のログイン状況監視できるアドミンページつくるのはダメかな？w 私の方でビューとかゴリゴリかきますので、、、

[xkumiyu]

adminページ作るのはいいけど、adminページならAPI経由じゃなくて直接モデルを操作するべきだと思う。

[hirokoji]

おけ、消してからpull requestします。

ただ、なぜくみちょうが直接モデルから操作するべきと思うかの理由を知りたいなぁ。勉強になるし。 REST APIな設計にするとAjaxで非同期でデータ持ってくることができるメリットがあると思うなぁ。

[matsu0228]

@hiro: セキュリティと利便性は、トレードオフだからね。。どっちも間違いじゃないと思う。

あとは、セキュリティ面のリスクをとってまで、その便利な機能を残す意味あるかってことでは？

リスク例：全ユーザー情報とれるAPIの使い方漏れたら、他人のふりして入室できちゃう可能性ある、とか

[hirokoji]

@matsu0228 コメントありがとう！！ セキュリティのためってことね♪ 最近、セキュリティ系のissueが多いし、 セキュリティレベルに関しては認識を合わすために一度議論したいなぁ。

それ次第で、今までのAPIのやつも全部直でデータベースいじった方ががよくない？ との結論になるきがしています♪

[ykubot]

一般的にどうやってるか調べてたいね。 RESTにするのがセキュリティ的によろしくないならこんなに推奨されてないはずだし。マルチプラットフォーム考えるならクライアントとサーバを疎結合にするメリットはあるはずだし。

[matsu0228]

ほんとはRegist/Delete/Getとかも、rails側で作ったほうがシンプル・セキュアだけど、 skyway発行のキー(window_id)を使って操作する必要があるから、実現にはAPIが必要なのです。

その分リスクがあって、たとえばdeleteAPI作ると他人を強制退室させたりできちゃう。不要なuser情報取得APIを残しておくと、すぐに他人のwindow_id取得して、退室させることができちゃうね。 ※本来は、同じ部屋のユーザでpeerがきれたユーザしかdeleteできないとか、チェック機能いれるべきだけど、window_idが漏れなければまずはそこまで要らないかなって思う（＝window_id漏れる機能は残すべきでない）。

一般的には↓とかかな。 ・利便性：アプリ化をみすえると、RestAPIで作っておくと汎用的に使える ・セキュリティ：認証いれたり、影響範囲少ない機能に絞りこんでおく必要あり。 認証について参考）http://www.roshi.tv/2014/08/rest-api.html

[hirokoji]

@matsu0228 まっつんの設計しそうとしては全てデータのやりとりはデータベース経由でやるべきだが、できないやつだけAPI経由にするべきってことね♪

自分的には データや機能によってセキュリティレベルを分類して、 それによって設計思想をかえるものだと思っていたわ。 トレードオフかどうかもそれによってきまると思ってた。 なぜなら、あだ名の情報だけをとられてもなんら問題ないと思うし。 また、情報を持っていても、利用できるインタフェースがなければ、無価値となるものもある。こういうのはAPIにキーをつけるとか、アクセスできるIPを絞るとか、セキュリティレベルをあげればいいのかなと思ってたよー。

[hirokoji]

とりあえず、使っていないAPI消してpull requestしました♪ セキュリティの議論はまた今度あったときにしましょう♪

マージいただいたら、このissueクローズします。