Open6

webを支える技術

T4R0T4R0

第1部第3章

restはアーキテクチャスタイル（アーキテクチャパターン）ほかにも mvcやパイプ&フィルタ、イベントシステムがある。→システムのアーキテクチャを決定する際の羅針盤。
デザインパターンは違う。

restはリソース（URI）という概念を持つ。URIを用いることでリソースが表現する情報にアクセスできる。URIはアドレス可能性という特徴を持つ。

サーバとクライアントでデータをやり取りすることをリソースの表現という。

restのアーキテクチャスタイル
クライアント/サーバ
ステートレスサーバ
restの視点から見るとcookieを使ったセッション管理は間違ったhttpの拡張（必要最低限の活用を推奨）
キャッシュ
一度取得したリソースを使い回すこと
統一インターフェース
階層化システム
コードオンデマンド
JavaScript等

restはweb全体のアーキテクチャスタイル

T4R0T4R0

第2部URI第4章

URIは統一リソース識別子
ホスト名はDNSで名前が解決できるドメイン名かIPアドレス
クエリパラメータやURIフラグメントといったパーツも持つ

絶対URIと相対URI

URIの実装で気をつけること
クライアントで相対URIを処理するのは面倒、できるだけ絶対URIを使うのが良い
ASC II文字以外を使う場合は文字エンコーディングの混乱を避けるためにutf-8を使うのが良い

T4R0T4R0

第2部第5章

良いURIはクールURIと呼ぶ
URIは原則変わらないべきである

変わりにくいURIで設計する

  • ある特定の実装言語に依存した文字列をURIに含めるとその言語を変更した途端に使えなくなる
  • メソッド名やセッションIDを含めない
  • リソースを表現する名詞にする

URI設計のテクニック

  • 拡張子で表現を指定する
  • マトリクスurl

URIを強く意識する

  • リソースの名前である
  • 寿命が長い
  • ブラウザがアドレス欄に表示する
T4R0T4R0

第3部第6章Httpの基本

TCP/IPとは

階層型プロトコル

インターネット層→ip

指定したipアドレスを送り先としてぱけっとたんいででーたをやりとりする。自分のネットワークインタフェースでデータを送ることだけを保証する

トランスポート層→Tcp

tcpは接続先の相手に対してコネクションを張る
TCPで接続したコネクションで転送するデータがどのアプリケーションに渡るか決定するのがポート番号。ポート番号は1〜65535がある。httpはデフォルトで80を使用。

アプリケーション層

メールDNS、httpを実現する層

HTTPのバージョン

HTTP0.9が最初のHTTP（仕様書は存在しない）
HTTP1.0は最初に標準化されたバージョン
HTTP1.1は1.0にチャンク転送、Accpetヘッダによるコンテントネゴシエーション等を追加したもの。ほとんどのクライアントライブラリ、WEBサーバハ1.1をサポートしている。

クライアントとサーバ

リクエストとレスポンス

クライアントで行われること

  1. リクエストメッセージの構築
  2. 送信
  3. （レスポンス待ち）
  4. レスポンスメッセージの受信
  5. 解析
  6. クライアントの目的を達成するのに必要な処理

サーバで行われること

  1. リクエスト待ち
  2. リクエストメッセージの受信
  3. 解析
  4. 適切なアプリケーションプログラムへの処理の委譲
  5. アプリケーションプログラムから結果を取得
  6. レスポンスメッセージの構築
  7. 送信

Httpメッセージ

リクエストメッセージ

リクエストライン
メソッドとリクエストURI、プロトコルバージョンから成り立つ
URIフラグメントを除いたパス以降の文字列がはい？
ポート番号はHostヘッダで指定する
ヘッダ
ボディ

レスポンスメッセージ

ステータスライン
プロコトルバージョンとステータスコード、テキストフレーズから成り立つ
ヘッダ
ボディ

Httpメッセージの構成

ステートレス性

ステートフルの欠点
クライアントが増えた時にスケールアウトさせにくい（サーバーがクライアントのリクエストを記憶するから）
ステートレスの利点
クライアントが増えた時に、サーバーを増やすことで簡単にスケールできる
ステートレスの欠点
送信するデータが多い
認証など、サーバに負荷がかかる処理を繰り返す

T4R0T4R0

第3部第7章Httpメソッド

8つしかないメソッド

主に使うのは6つ

CRUD

GET

リソースの取得

POST

リソースの作成、追加

子リソースの作成

リソースへのデータの追加

他のメソッドで対応できない処理

URIのキーワードが長過ぎてGETできない時、POSTでリクエストボディにキーワードを含めることができる

PUT

POSTとPUTの使い分け

特別な理由がない場合、リソースの作成はPOSTで行う（Putだとサーバとクライアントの結合が密）

Postでput/deleteを代用する

6つの中でもGetとPostが1番利用される。htmlのフォーム指定できるメソッドがGetとPostだけという制限がある。（現在は解消されつつある。）
GetとPostしか使えない制限があるときにput deleteを使う方法が２つある

_methodパラメータ

X-http-method-override

条件付きリクエスト

if-modified-sinceヘッダが入ったGETはリソースがこの日時以降更新されていたら取得する。こんなことができる

べき等性と安全性

通信エラーが発生した時にリクエストをどのように回復するか。
べき等とは、ある操作を何回行っても結果が同じこと。（put、delete）
安全とは操作対象のリソースを変更させないこと。（get）

Webの成功理由はHTTPめそっどにあり

GETに隠された安全性、putとdeleteのべき等性。いざとなったらなんでもできるPost。