RESTの考え方を理解する
RESTってなんだ？
Webサービスの設計モデルらしい。REST化したWebサービスはHTTPメソッドでアクセスするとデータの送受信をクライアントとサーバーサイドでやりとりしてくれる。
色々あるアーキテクチャスタイルのうち、クライアント／サーバーの設計が有名である。そのうちのRESTはアーキテクチャの中で色々と制約をつけてコンパクトにしたもののイメージ。
そしてRESTは複数のアーキテクチャスタイルから組み合わせて構築した複合アーキテクチャスタイルを指す。
RESTアーキテクチャの構成
- ステートレスサーバー
- キャッシュ
- 統一インターフェース
- 階層化システム
- コードオンデマンド
この1~4項目に即したWebサービスはRESTfulと言われる。
リソースとは？
Web上の名前を持ったありとあらゆる情報 このリソースを識別するにはURIを使います。
URI
統一リソースの識別子 これにより全てのリソースを一意に示せる。
URIが備える、リソースを簡単に指し示せる性質はアドレス可能性と呼ぶ。 リソースに対して名前がついていて、適切な手段でアクセスできる状態
http://blog.example.jp/entries/1
これをそれぞれ分解すると・・・
こんな感じになる。
他にも、
- ポート番号
- クエリパラメータ
- URIフラグメント
がつくアドレスもあるよ。
クエリパラメータは検索で何かデータを渡したときに入ります。
それぞれの役割
1 ステートレスサーバー
サーバーはクライアントのセッション情報を保持しません。
多数アクセスに対してセッション情報を保持し続けて、アクセスに対してそれを提示するのは大変。 なのでステートレスがいいという話（多分）
2 キャッシュ
これは以前サイト作成で苦戦した覚えがある。 クライアントサイドで訪問したサイトのデザインやらを記憶している。
ネットアクセスが読み込みスムーズになるメリットに対して、リソースを色々変更した場合に反映しにくい。 キャッシュを削除しないと更新状態が見えなかったりする。
ウルトラリロードとかつけてた気がする。（そんな名前の機能だったかも忘れた）
3 統一インターフェース
CRUDもRailsの知識として聞いたことがある。 URIのリソースに対してHTTPメソッドそれぞれ操作するよ。
| 処理 | HTTPメソッド | CRUD操作 |
|---|---|---|
| 登録 | POST | CREATE |
| 取得 | GET | READ |
| 更新 | PUT | UPDATE |
| 削除 | DELETE | DELETE |
処理結果に対する返答のステータスコード
| コード | 状態 | 説明 |
|---|---|---|
| 200 | OK | リクエストが正常に処理された |
| 201 | Created | リクエストが正常に処理され、新規リソースが作成された |
| 204 | No Content | リクエストが正常に処理されたが、返す新規情報はない |
| 400 | Bad Request | サーバーが理解できない無効な要求である |
| 401 | Unauthorized | 要求されたリソースには認証が必要である |
| 403 | Forbidden | 要求されたリクエストは拒否された |
| 404 | Not Found | 要求されたリソースはサーバーに存在しない |
| 500 | Internal Server Error | サーバーでエラーが発生した |
4 階層化システム
サイドバーのカテゴリとかも階層構造になってたりしますね。プログラムのディレクトリの階層構造も然り。
何となくイメージできるものは説明は割愛。
5 コードオンデマンド
プログラムをサーバーからダウンロードし、クライアント側で実行するアーキテクチャスタイル ex:Javascript, Flash,Java アプレット
クライアント側をあとから拡張できるよ。
でもアプリケーションのプロトコル可視性は低下する懸念もある。
引用：qiita.com
引用：
ツイッターのER図を作る
正規化がとても難しい
正規化については、動画と著書で6割理解と後残りは実践だと思ってる。
正規化とは？
- 表の横方向の重複整理
- テーブルごとの縦方向の重複整理
- 1対nの関係で切り出していく
第２正規化がまだいけるんじゃない？の自問自答で煮詰まる。
ひとまずpostalkでざっくりリスト化
最初こんな感じで考えた
でもテーブルごとにID付与しないとだめだよね・・・？
ひとまず、リスト化はここまでで作ってみる。
draw.ioでER図作成
draw.ioのsoftwareを選ぶと使いやすい。鳥の足とか用意してくれてる。
1対nの意識が難しい・・・
課題とモヤモヤ
- まだ正規化できるんじゃないか？やっていいのか？という迷い
- 特に画像のテーブルを作った方が良いか？
- ハッシュタグはプロフィールやツイートごとのテーブルにそれぞれ付与でいいかな？
重複するようなものなのか、煮詰まると正確に判断できなくなってくるなあ。
ER図について正規化の考え方
ER図の正規化についてまとめる。
なるほどなるほど正規化
第1正規化から第3正規化まであるけれどちょっとわけがわからなかった。 やってることがなんとなくわかるようでわからないというイメージ。
この動画を見るまでは「重複をなくす」というイメージのみでした。
わかりやすい動画発見
これはわかりやすい・・・ ER図がちょっとだけ書けそうと思った。
ふむふむ。
正規化は表の縦と横の繰り返しをなくす
正規化のステップ
第一正規化👉横方向の繰り返しをなくす
第二正規化👉縦方向の繰り返しをなくす
この順番の様子。
あまり使わない言葉は覚えなくてOK
現場で使うのかなと思いきや、使わない言葉もある様子。
エンティティが記憶に残りにくい、なんとなく要素として捉えていたからそこまで深く覚えなくて良い。ということでありがたい。
早速課題を修正していこうかな
課題でツイッターER図作成があるので、ひとまず自分で表が作れるようにしたいと思う。 一回なんとなくで出してしまっているので修正項目が多い。
リストについてもなんとなくなイメージがある。要確認。
正規化ができないと設計できないよね
データベース使うWebサイトやアプリを作るなら避けて通れない・・・と思って、しっかり学習していきたい。
デザインやサイト・アプリの仕様は変わってもここは変わらず残るもの、デジタルタトゥー以上に残るものなので、しっかり学習していきたい。
うーむ。
