よちよち.rb & Sendagaya.rb 合同開催「よちがや.rb」 〜REST アーキテクチャを理解しよう会〜
2019/01/07 に開催された「よちよち.rb & Sendagaya.rb 合同開催「よちがや.rb」 〜REST アーキテクチャを理解しよう会〜」に行ってきました。内容の詳細については下記のページをご覧下さい。
当日のスライド
当日、Toru KAWAMURA さんが発表されたスライドは以下のとおりです。
当日のメモ
私が当日書いたメモは以下のとおりです。殴り書きに近い部分もありますがご了承下さい。また、話の中で出た URL という単語は URI と記述しています。
よちよち.rb & Sendagaya.rb 合同開催「よちがや.rb」 〜REST アーキテクチャを理解しよう会〜
RailsスタイルからRESTを学ぼう
RESTとは
- Railsチュートリアルより
アーキテクチャのスタイルである
- 2つの意味があり、それが混在されて使用されてしまっている
- アーキテクチャの意味
- HTTPでのやりとりの意味
- Webの仕組みを形作るための「制約」
- 「制約」は重要
- ルールを定めることでそれに乗っかれば綺麗になる
- 統一したアーキテクチャスタイルが実現できるから
- メリット
- URI、HTTP、HTMLのメリットを活かせる
- リンクをたどってアプリを使える（人間に優しい）
- curlで簡単に扱える
- SOAPより格段に扱いやすくなった
- シンプルな設計なためプログラマに優しい（基本は4種類）
- URI/HTTP/HTML/JavaScriptを「正しく」使えれば REST は満たせる
Webブラウザ（デベロッパツール）で見る
- 以下が重要
- リクエストURI
- リクエストメソッド
- ステータスコード
- URI
- Web上に存在するモノ（リソース）の名前
- URIを示しさえすれば完結する
- 設計する際はシンプルで意味が分かりやすいものにする
- Web上に存在するモノ（リソース）の名前
- リクエストメソッド
- GET/POST/PUT/DELETE
- CRUD
- DBとの対比
- 同じURIに対して4つの操作ができる
- URIは「名詞」、メソッドは「動詞」
- 設計する場合はこれを意識する
- URIに「動詞」は入らない
example.com/users/createはあり得ないexample.com/users/12345が正解
- 動詞はメソッドで表現する
- リクエストメソッドの特徴
- GET
- 安全（リソースが変更されない）
- POST
- （なし）
- PUT
- 冪等
- POSTとPUTの大きな違い
- DELETE
- 冪等
- GET
- ステータスコード
- 成功 or 失敗とその理由
- 2xx/3xx/4xx/5xx
Webのパーツを学ぶ
- 命名について
- Railsスタイル（通称）のリソース設計は成功している
- Rails以降のフレームワークでも採用されている
- 学ぶ価値がある
- /
まとまり/名前 or 番号という URI設計- /users
GET/POSTのみ
- /users/12345
GET/PUT/DELETEのみ
- 以下は補助的（なくてもいい）
- /users/new
- /users/12345/edit
- 7つの「アクション」がコントローラに作られる
まとまりの名前は当然に「複数形」
- /users
- 「リクエストメソッドが当てはまらないときは、隠れたリソースがある」という考え方
- 新しいリソースを定義するとうまくいくことがある
PUTとPATCHの違い
- Rails 4 ぐらいから PUT でなく PATCH になった
- PUTの定義
- リソースを「全て」書き換える
冪等である
- PATCHの定義
- リソースを「部分的に」書き換える
冪等でない
- 例としてはインクリメントを考えるとよい
- 投げた回数だけ数が増えるので冪等だとまずいのでPATCHが適切
- PUTの定義
- 5種類のメソッドになるのでは？
- OPTIONSというメソッドもあるしそれ以外もメソッドはあるので存在としては5種類以上になる
- RESTがCRUDの4種類に制約しているということ
- 発展として、プロキシがメソッドを制約しているといろいろダメだが現実的には問題ない
リソースのネストについて
- 原則としてネストは最小限にする
- Rails Guide「2つまでにしておけ」
- URIの「見た目」も大事
情報秘匿のために GET でなく POST を使うことについて
- 他にも URI の見た目を考えて（パラメタがゴテゴテつくのを嫌って）POSTを使うなど
- 結論
- GETでだめならPOSTでよい、とHTTPで定まっているので問題なし
ログイン操作（トークンを伴う場合など）はどのメソッドか？
- 「安全」と「冪等」の観点から考えると設計が分かりやすくなる
- トークンは一回限りで破棄か？
- cf. セッションというリソースを作るという設計
- POSTが大半、場合によってPUTか
「隠れたリソース」の気づき方
- 4つのメソッドに当てはまらない→リソース探す→見当たらない……
- 「ユーザーがグループに加入する」
- 「加入する」という動詞に着目すればいい
- 動詞を名詞に変換するといい
設計の目標
- すべて
resources :foobarでルーティングできるのが理想
その他
- 「Webを支える技術」を読んどけ
感想
初学者向けということでしたが、得られるものが多く、大変勉強になりました*1。すでに自分が知っていたことについても、その知識が間違っていなかったという再確認にもなり、充実した時間を過ごせました。
懇親会を含め*2、Rubyコミュニティの優しさも再認識しました。次回の機会にもぜひ参加したいと思います。
懇親会*3
