現場Rails Chapter6 RESTfulについて
RESTfulの概要について
まずRESTってなに？
REST（REpresentational State Transferの略）とはアプリケーションの設計方法の一つ。
操作の対象となるリソースをURLを使って表し、それに対して、HTTPメソッドの「GET」「POST「DELETE」「PUT」などを使って操作を行うというもの。
インターネットそのものやWebアプリケーションなどの、分散・ネットワーク化されたシステムやアプリケーションを構築するためのアーキテクチャのスタイルの一つ。
RailsアプリケーションにおけるRESTとは
アプリケーションを構成するコンポーネント（ユーザやマイクロポストなど）を「リソース」としてモデル化することを差す。
これらのリソースはリレーショナルデータベースのCRUD操作とHTTPメソッドの両方に対応している。
↓
要するにRESTfulって
用意されたHTTPメソッドを使ってCRUD機能を手軽に操作できる型みたいなものという認識。
RESTfulなスタイルにすることで、作成すべきコントローラやアクションの決定が楽になる。
CRUDを行うリソースだけでアプリケーション全体を構成してしまうこともできる。
もっと具体的に！！！
RESTfulは以下4つに当てはまるもののことをいう。
⑴ HTTPリクエストはそのリクエストで必要な情報をすべて持ち、前のリクエストからの状態が保存されている必要がない。（ステートレスな状態という）
⑵ 個々の情報（リソース）への「操作」の表現がHTTPメソッドとして統一されている。⇦これ一番大事！！
⑶ 個々の情報（リソース）がそれぞれ一意なURI（ここではURLの認識でOK）で表されている。
⑷ ある情報（リソース）から別の情報を参照したいときは、リンクを利用する。
RESTfulの主な特徴
・URLが表す情報のことをリソースと呼ぶ。
（例：「/tasks/13というURLが示しているのは13という一意な識別子を持つtaskのリソースだ。」といった感じ)
・⑵の理由により、RailsではGETやPOST以外にPATCH、PUT、DELETE のサポートもする。
・⑵の理由により、RESTfulなシステムでは、操作はHTTPメソッドで表現するものであり、URLで表現するものではない。
なのでURLはなるべく情報（リソース）の名前を表す形にするという発想で作られている。
参考
現場Rails Chapter6 ルーティングについて
ルーティングとは
アクセスを受けて適切なアクションへと案内する仕組みのこと。
「どのようなURLへどのようなHTTPメソッドでアクセスされたら、どのコントローラのどのアクションを呼び出したいのか。」をconfig/routes.rbに定義する。
ルーティングを構成する5つの要素を理解する
HTTPメソッド（GET、POST、PATCH、PUT、DELETE）
・サーバへリクエストする際に指定するもの。
・情報の送信や取得する方法を表すもの。
・一般的にはブラウザから送ることができるのはGETとPOSTのみ
Railsの場合、methodというパラメータの値に"PATCH"、"PUT"、"DELETE"という文字列が入ったPOSTリクエストをそれぞれPATCH、PUT、DELETEと解釈する。
URLパターン（/users, users/:id）
・定義したURLパターンごとに一意な名前をつける。
・対応するURLを生成するためのヘルパーメソッド
（new_user_path、new_user_urlなど）が用意されている。
コントローラ (usersではUsersController)
・呼び出したいアクションのコントローラクラスを指定する。
アクション（index, new, createなど）
・呼び出したいアクションを指定する。
これらの要素がどの塔に利用されているのかを表したのが、下の図。
もう一つの働き方として URLパターンに名前をつけておいてその名前を元にURLを簡単に生成するためのヘルパーメソッドを作り出す。
HTTPメソッド と URLパターン を指定して コントローラ の アクション を実行 【GET】 【/users】 → 【UsersController】 【index】 ↓ ↓ URLパターン名 を指定して URLヘルパーメソッド を実行 【users】 → 【users_path】
例：config/routes.rb
get '/login', to: 'sessions#new'
GETメソッドで"/login"というURLに対してリクエストが来たら
SessionsControllerのnewアクションを呼び出す。
また、'/login'というURLを'login_path'というヘルパーメソッドで生成できるようになる。
例：config/routes.rb
post '/login', to: 'sessions#create'
POSTメソッドで"/login"というURLに対してリクエストが来たら
SessionsControllerのcreateアクションを呼び出す。
また、GETと同様にURLパターン名はloginになる。
※URLパターン名はルートごとというより、URLパターンごとにつけるものと理解しておく。
実際にどのようなルーティングになっているかrails routesコマンドで確認する。
また、GET、POST以外で、patch, put, deleteの各HTTPメソッドに対応する定義が可能。
getなどの代わりにmatchと:viaオプションの組み合わせを使うと複数のHTTPメソッドを受け付ける定義ができる。
match 'login', to: 'sessions#create', via: [:post, :patch, :put]
authenticateメソッドについて
authenticateメソッドとは
Userクラスにhas_secure_passwordと記述したときに自動で追加された、認証のためのメソッド。
引数で受け取ったパスワードをハッシュ化してその結果がUserオブジェクト内部に保存されているdigestと一致するかを調べる。
一致していたら認証成功ということでUserオブジェクト自身を、一致していなければ認証失敗ということでfalseを返す。
セッションとCookieについて
ログインしたときやカートにものを入れたとき
例として、もしWebサイトにログインや何か商品をカートに入れる場面があったとします。
ログインしたはずなのにログインできていないことになっていたり、商品を買い物かごに入れたはずなのに、次の画面に進むと商品が入っていないと認識されてしまってはWebサイトとして成り立たない。
クライアントであるブラウザにセッションとしてユーザーの情報を持ち続けることでステートレス（ユーザが入力した情報を記憶せずに、次の動作を行うこと）なHTTP通信でもリクエストを特定のユーザーの情報として受け取ることができる。
セッションとは
Webアプリケーションは、ブラウザからサーバへHTTPリクエストを送ってから、HTTPレスポンスを受け取って画面に表示する。
HTTPはステートレスなプロトコルなので、そのままユーザから送られた1つ目のリクエストから2つ目のリクエストに引き継ぐことができない。
そこで、サーバ側にセッションという仕組みを用意して、一つのブラウザから連続して送られる一連のリクエストの間で「状態」の共有できるようにしている。
Cookieとは
ブラウザに保存される小さな情報またはその領域のことを言う。
セッションがアプリケーションサーバ側で独自に実現される仕組みに対して、CookieはWebブラウザとサーバの間でやりとりされる仕組み。
Coolkieでは、まずWebサーバからブラウザへHTTPレスポンスを返すときに、なんらかのCookie情報を含めて送っている。
Cookie情報は、キーと値が集まったもの。
ブラウザはこのCookie情報をサーバのドメインなどの情報に紐づけて保存する。
次に同じドメインに対してHTTPリクエストを送る際に、保存していたCookieの情報を添えて送る。
これによって、Webサーバは、以前にどのようなCookie情報を受け取ったブラウザからリクエストが送られてきたのかを把握することができる。
Cookieは複数のリクエストの間で共有したい「状態」をブラウザに保存する仕組みのことをいう。
ログイン機能を実装する前に知っておくべき知識
クライアントからサーバに特定の情報を渡す方法
① GETリクエストのURLパラメータにクエリ文字として記載して残す
→ URLパラメータはユーザに見えるので、簡単に変更できてしまうので❌
② POSTリクエストのリクエストボディに内容を含めて渡す
→ POSTリクエストの内容は、ブラウザの開発者用ツールを使って確認や変更ができてしまうので❌
③ Cookieに保存してリクエストを送る
→ 基本的にはこの方法で、ブラウザのCookieをセッション情報の保存先にしている⭕️
参考
・【Rails】ログイン機能を実装する上で必要不可欠な「Session」について解説｜TechTechMedia
・Rails セキュリティガイド - Railsガイド
form_withの中にあるlocal: trueって何？
local: trueとは
公式ドキュメントによると「リモート送信の無効（デフォルトはfalse）」とのこと。
local: trueを記述しない場合は、非同期通信（Ajaxによる通信）が行われることになる。
local: trueを入力することで、非同期通信をせず、HTMLとしてフォームが送信できるようになる。
参考
・form_with | Railsドキュメント
・【IT用語】 | Pikawaka - ピカ1わかりやすいプログラミング用語サイト
i18nを使って日本語対応
i18nとは
ソフトウェアを特定の地域の言語、仕様に縛られることなく、世界各国で共通して利用できるようにすることを意味する。「Internationalization」を省略した表記方法のこと。
Railsのエラーメッセージやコンテンツは英語表記になっているので、英語以外の言語を使いたい場合は、言語ごとに翻訳を追加する必要がある。
1.方法1：gemrails-i18nをインストールする or
1.方法2：GitHubのi18nリポジトリから翻訳ファイルをダウンロードする
curl -s https://raw.githubusercontent.com/svenfuchs/rails-i18n/master/rails/locale/ja.yml -o config/locales/ja.yml
2.デフォルトの言語を日本語にする
config/application.rb
config.i18n.default_locale = :ja
3.i18nのロケールファイルが読み込まれる為のパスを通す
config/application.rb
config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}').to_s]
4.config/locales以下にロケールファイルを配置する
※viewとmodelは絶対分ける 配置は以下の感じ
config
└── locales
├── model.ja.yml # modelは1つのファイルで管理
└── views # views関連のファイルはここで管理
├── admin
│ ├── dashboards
│ │ └── ja.yml
│ ├── ja.yml
│ ├── user_sessions
│ │ └── ja.yml
│ └── users
│ └── ja.yml
├── boards
│ └── ja.yml
├── dashboards
│ └── ja.yml
├── password_resets
│ └── ja.yml
├── shared
│ └── ja.yml
├── user_sessions
│ └── ja.yml
└── users
└── ja.yml
5.ja.ymlに日本語を設定する
※ビューはビューで格納しているフォルダ名を起点にして、ビュー名毎に記述する。
※インデントに注意！
viewの日本語化設定
config/locales/views/users/ja.yml
ja:
users:
new:
first_name: "名"
last_name: "姓"
email: "メール"
image: "プロフィール画像"
password: "パスワード"
password_confirmation: "パスワード確認"
submit: "登録"
login: "ログインはこちら"
modelの日本語化設定
※モデルは全てactiverecord以下に記述する
※activerecord以下に記述することで、
User.model_name.human / User.human_attribute_name({attr_name})で使用可能になる。
config/locales/model.ja.yml
ja:
activerecord:
models:
user: ユーザー
board: 掲示板
attributes:
user:
id: ID
first_name: 名前
last_name: 姓
email: メールアドレス
file: プロフィール画像
crypted_password: パスワード
attributes:
created_at: 作成日
updated_at: 更新日
6.設定した日本を表示させる
viewで使用するときは、<%= t.'.title' %>みたいな感じで使える。
modelで使用するときは、<li><%= User.model_name.human %></li>で「ユーザー」が表示される。
参考
・Rails 国際化 (i18n) API - Railsガイド
・https://github.com/svenfuchs/rails-i18n
・I18nとは何？ Weblio辞書
・[初学者]Railsのi18nによる日本語化対応 - Qiita
i18nを使って日本語対応
i18nとは
ソフトウェアを特定の地域の言語、仕様に縛られることなく、世界各国で共通して利用できるようにすることを意味する。「Internationalization」を省略した表記方法のこと。
Railsのエラーメッセージやコンテンツは英語表記になっているので、英語以外の言語を使いたい場合は、言語ごとに翻訳を追加する必要がある。
1.方法1：gemrails-i18nをインストールする or
1.方法2：GitHubのi18nリポジトリから翻訳ファイルをダウンロードする
curl -s https://raw.githubusercontent.com/svenfuchs/rails-i18n/master/rails/locale/ja.yml -o config/locales/ja.yml
2.デフォルトの言語を日本語にする
config/application.rb
config.i18n.default_locale = :ja
3.i18nのロケールファイルが読み込まれる為のパスを通す
config/application.rb
config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}').to_s]
4.config/locales以下にロケールファイルを配置する
※viewとmodelは絶対分ける 配置は以下の感じ
config
└── locales
├── model.ja.yml # modelは1つのファイルで管理
└── views # views関連のファイルはここで管理
├── admin
│ ├── dashboards
│ │ └── ja.yml
│ ├── ja.yml
│ ├── user_sessions
│ │ └── ja.yml
│ └── users
│ └── ja.yml
├── boards
│ └── ja.yml
├── dashboards
│ └── ja.yml
├── password_resets
│ └── ja.yml
├── shared
│ └── ja.yml
├── user_sessions
│ └── ja.yml
└── users
└── ja.yml
5.ja.ymlに日本語を設定する
※ビューはビューで格納しているフォルダ名を起点にして、ビュー名毎に記述する。
※インデントに注意！
viewの日本語化設定
config/locales/views/users/ja.yml
ja:
users:
new:
first_name: "名"
last_name: "姓"
email: "メール"
image: "プロフィール画像"
password: "パスワード"
password_confirmation: "パスワード確認"
submit: "登録"
login: "ログインはこちら"
modelの日本語化設定
※モデルは全てactiverecord以下に記述する
※activerecord以下に記述することで、
User.model_name.human / User.human_attribute_name({attr_name})で使用可能になる。
config/locales/model.ja.yml
ja:
activerecord:
models:
user: ユーザー
board: 掲示板
attributes:
user:
id: ID
first_name: 名前
last_name: 姓
email: メールアドレス
file: プロフィール画像
crypted_password: パスワード
attributes:
created_at: 作成日
updated_at: 更新日
6.設定した日本を表示させる
viewで使用するときは、<%= t.'.title' %>みたいな感じで使える。
modelで使用するときは、<li><%= User.model_name.human %></li>で「ユーザー」が表示される。
参考
・Rails 国際化 (i18n) API - Railsガイド
・https://github.com/svenfuchs/rails-i18n
・I18nとは何？ Weblio辞書
・[初学者]Railsのi18nによる日本語化対応 - Qiita
