一覧表
タイトルのように、横一線で覚える方が実用的だと思い、まとめました！
Userモデルを例に
| CRUD | HTTPメソッド | アクション | URLパターン | ヘルパーメソッド | 内容 |
|---|---|---|---|---|---|
| Read | GET | index | /users | users_path | ユーザー一覧ページの「表示」 |
| Read | GET | show | /users/(1) | user_path | ユーザーのページを「表示」 |
| Read | GET | new | /users/new | new_user_path | ユーザー作成ページの「表示」 |
| Create | POST | create | /users | users_path | ユーザーの『作成』 |
| Create | PUT | create | /users/(1) | user_path | 指定ユーザーに関わる『作成』 |
| Read | GET | edit | /users/(1)/edit | edit_user_path | ユーザー編集ページの「表示」 |
| Update | PATCH | update | /users/(1) | user_path | ユーザー情報の一部を『更新』 |
| Update | PUT | update | /users/(1) | user_path | ユーザー情報の全体を『更新』 |
| Delete | DELETE | destroy | /users/(1) | user_path | ユーザーの『削除』 |
補足
POST, PUTの違い
- リソースを指定した操作なのかどうかの違いと、結果が冪等であるかどうかの違い（後ほど冪等性について解説）
PUT, PATCH の違い
- ユーザー情報を一部更新する（PATCH）のか、まるっと全てを更新する（PUT）のかで判断
冪等性（べきとうせい）
冪等性は、何度やっても同じ結果を返すことという意味ですが、ここで覚えることは、
-
POSTが唯一、HTTPメソッドの中で冪等性がない
ということです。
例えばユーザーを作成するcreate（POST）の実行結果を考えてみると、毎回違うユーザーが作成されるはずですね。
その他のメソッドは常に1つの結果にしかなりません。（destroyなどの一回しかやらない操作も、1つの結果であることは同じ）
以上、RESTfulなリソース選定にご参考にしていただければ幸いです！