「Webを支える技術」のメモです。
3部HTTP
6章 HTTPの基本
HTTPは、RESTの重要な特徴である統一インターフェース、ステートレスサーバ、キャッシュなどを実現している、Webの基盤となるプロトコルです。
また、HTTPは、TCP/IPをベースにしています。
クライアントとサーバ
Webはアーキテクチャスタイルに、クライアント/サーバを採用しています。そしてHTTPでは、
クライアントが出したリクエストをサーバで処理を行ってからレスポンスを返します。
サーバでの処理時間がかかる場合でも、リクエストを出したクライアントはレスポンスが返るまで待機します。これはHTTPが同期型のプロトコルであるためです。
クライアント側で行われること
クライアントは、一つのリクエストを送信し、レスポンスを受信する際に、次のことを行います。
・リクエストメッセージの構築
・リクエストメッセージの送信
・レスポンスが返るまでの待機
・レスポンスメッセージの受信
・レスポンスメッセージの解析
・クライアントの目的を達成するために必要な処理
サーバで行われること
クライアントからリクエストを受けたサーバは、次のことを行います。
・リクエストの待機
・リクエストメッセージの解析
・適切なアプリケーションプログラムへの処理の委譲
・アプリケーションプログラムから結果を取得
・レスポンスメッセージの構築
・レスポンスメッセージの送信
HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめて、「HTTPメッセージ」と呼びます。
リクエストメッセージ
1.リクエストライン
リクエストメッセージの一行目は「リクエストライン」と呼び、メソッド(GET等)、リクエストURL、プロトコルバージョンから成り立ちます。
2.ヘッダ
リクエストメッセージの2行目以降はヘッダが続きます。ヘッダはメッセージのメタデータです。
1つのメッセージには複数のヘッダを持つことが出来ます。
3.ボディ
ヘッダの後にボディが続くことがあります。ボディには、そのメッセージが表す本質的な情報が入ります。
レスポンスメッセージ
1.ステータスライン
レスポンスメッセージに1行目は「ステータスライン」と呼び、プロトコルバージョン(HTTP/1.1等)、ステータスコード(200等)、テキストフレーズ(OK等)から成ります。
2.ヘッダ
レスポンスメッセージの2行目以降は、リクエストメッセージと同様にヘッダです。
3ボディ
こちらもリクエストメッセージと同様です。
HTTPのステートレス性
HTTPはステートレスなプロトコルとして設計されています。
ステートレスとは、サーバがクライアントのアプリケーション状態を保存しないということです。
こちらの記事を見てもらうと分かりやすいです。(テキストと同じないようなので、引用させてもらいました笑)
ステートレスとは
サーバがステートフルな場合、サーバがクライアントの状態を覚えます。しかし、クライアントの数が増えれば増えるほど、サーバの負荷が大きくなり、スケールアウトしにくい設計となります。
この問題を解決するのがステートレスなアーキテクチャです。ステートレスサーバでは、処理に必要な情報はすべてクライアントからのリクエストに含まれており、各クライアントが自身のアプリケーション状態を(覚えて)伝えるので、サーバ側のシステムは簡素になります。
HTTPメソッド
8つしかないメソッド
HTTPメソッドには、クライアントが行いたい処理をサーバに伝えるという重要な役割があるのにも関わらず、8つのメソッドしか用意されていません。
・GET/リソースの取得
・POST/子リソースの作成、リソースへのデータの追加、その他の処理
・PUT/リソースの更新、リソースの作成
・DELETE/リソースの削除
・HEAD/リソースのヘッダ(メタデータ)の取得
・OPTION/リソースがサポートしているメソッドの取得
・TRACE/自分宛てにリクエストを返す試験
・CONNECT/プロキシ動作のトンネル接続への変更
これほどにメソッドの数を限定したからこそ、HTTPが(Webが)成功したともいえます。
べき等と安全性
通信エラーが発生した場合に、リクエストをどのように回復するかは、HTTPにおいて重要な課題です。HTTPの使用では、プロトコルのステートレス性を保ちながら、この問題を解決するための工夫がなされています。
次の表を見てみましょう。
| メソッド | 性質 |
|---|---|
| GET,HEAD | べき等かつ安全 |
| PUT,DELETE | べき等だ安全ではない |
| POST | べき等でも安全でもない |
べき等とは、「ある操作を何回行っても結果が同じこと」を意味します。
PUTやDELETEを同じリソースに何回発行しても、必ず同じ結果(リソースの内容が更新されている、削除されている)が得られます。
安全とは、「操作対象のリソースに副作用が無いこと」を意味します。
副作用とは、リソースの状態に変化を与えることを言います。
GETには副作用が無いので、GETを同じリソースに対して何回発行しても、リソースの状態は変化しません。
※べき等でも安全でもないPOST
POSTはべき等でも安全でもないので、使用する際は必要です。
例えば、ショッピングサイトでブラウザの戻るボタンを押した場合に「もう一度送信しますか？」というダイアログが出ることがあります。これはPOSTを再送信しようとしているからです。もしダイアログが出現しない場合、自動的にPOSTを再送信してしまい、二重注文になってしまします。