Webを支える技術：HTTP概要

Webサーバ関連 Webアプリケーション Webを支える技術

HTTPメソッド概要

8つのメソッド

メソッド名 役割
GET リソースの取得
POST ・子リソースの作成
・リソースへのデータ追加
・そのほかの処理
PUT ・リソースの更新
・リソースの作成
DELETE リソースの削除
HEAD リソースのヘッダ（メタデータ）の取得
※メタデータ：データを説明するデータ
OPTIONS リソースがサポートしているメソッドの取得
TRACE 自分宛にリクエストメッセージを返す試験（ループバック）
CONNECT プロキシ動作のトンネル接続への変更

『POSTもPUTもリソース作成できるけど、どういう使い分けがある🤔？』と思ったけど、説明がちゃんとありました🤗

明確な正解はないが、設計指針として次の事実があるらしい。

POSTでリソースを作成する場合、クライアントはリソースのURIを指定できません。URIの決定権はサーバ側にある。 逆にPUTでリソースを作成する場合、リソースのURIはクライアントが決定します。

具体的な例だと、TwitterのつぶやきのURIはサーバ側で決定されるのでPOSTを用いて、Wikipediaはクライアントが決定したタイトルがURIになるのでPUTが用いられるのが一般的らしい。

上記の違いから、POSTの場合、作成されたリソースのURIをクライアントはわからないため、リクエストメッセージのレスポンスのLocationヘッダでURIを受け取る。一方、PUTの場合は、クライアントがURIを決定できるため、レスポンスでLocationヘッダが返される必要はない。

べき等性と安全性

HTTPメソッドにはべき等性と安全性という性質がある。べき等性は『ある操作を何回行っても結果が同じ』ことを意味し、安全性は『操作対象のリソースの状態を変化させない』ことを意味する。よく使われるメソッドについて、性質をまとめる。

メソッド名 性質
GET、HEAD べき等かつ安全
PUT、DELETE べき等だが安全でない
POST べき等でも安全でもない

例えば、GETはリソースを取得するだけなので『べき等かつ安全』、PUTはリソースに何回発行しても同じ結果（リソースの内容が更新される）になるので、『べき等でないが安全』となる。

注意としては、WebサービスやWeb APIの実装として、上記の性質を守るように設計することが大事。設計を誤るとGETにおいてもリソースの削除をさせることができてしまうため。

ステータスコード

ステータスコードは３桁の数字で、先頭数字により5つに分類される。

コード 分類 説明
1xx 処理中 処理が継続していることを示す。
2xx 成功 リクエストが成功したことを示す。クライアントはリクエストを継続するか、サーバ指示に従いプロトコルをアップデートして再送信する。
3xx リダイレクト ほかのリソースへのリダイレクトを示す。クライアントはこのステータスコードを受け取ったら、レスポンスメッセージのLocationヘッダを見て新しいリソースへ接続する。
※リダイレクト：別のURIにクライアントが自動的に再接続する処理。
4xx クライアントエラー エラー原因がクライアント側にあるエラー。エラーを解消しないと正常結果を受け取れないため、同じリクエストの再送信はできない。
5xx サーバエラー エラー原因がサーバ側にあるエラー。サーバ側の原因が解消されれば、同一リクエストを再送信して正常な結果を得られる可能性がある。

ここでのポイントしては、リダイレクトもサーバ側が実装しておかないとリンク切れを起こすという点。WebサービスやWeb APIでエラーが起きた時に、どのエラーステータスコードを返すかは、重要な設計の検討事項の一つ。

HTTPでの認証

あるリソースにアクセス制御がかかっている場合、ステータスコード401:Unauthorized(このリソースのアクセスには適切な認証が必要)とWWW-Authenticateヘッダを利用することで、クライアントにリソースへのアクセスに必要な認証情報を通知することができる。

HTTP認証方式には、次のものがある。

方式名 説明
Basic認証 ユーザ名とパスワードをBase64エンコードした文字列を、Authorizationヘッダに入れて送信する。Base64エンコーディングは簡単にデコードできるので注意。注意としては、メッセージ自体は平文のため、セキュリティ的にはHTTPS対応を利用する方が良い。
Digest認証 あるメッセージに対してハッシュ関数を適用した結果のハッシュ値を用いて送信する。サーバからのチャレンジに対して、クライアントはダイジェストを生成し、nonce:nubmber used onceとqop:quality of protectionを連結したメッセージをサーバに送信する。注意としては、メッセージ自体は平文のため、セキュリティ的にはHTTPS対応を利用する方が良い。
WSSE HTTP1.1の標準外の認証方式。AtomPubなどのWebAPIで使われる。

キャッシュ用ヘッダ

キャッシュは、サーバから取得したリソースをクライアントのローカルストレージに蓄積し、再利用する手法のこと。蓄積されたキャッシュは、そのキャッシュが有効な間、クライアントが再度当該リソースにアクセスしようとするときに再利用される。

キャッシュ用のヘッダとして次のものがある。

ヘッダ名 説明
Pragma キャッシュを抑制する(リソースのキャッシュを制限する)
Expires キャッシュの有効期限を設定する
Cache-Control 細かくキャッシュを制御する

使い分けの方針は次の通り。

  • キャッシュさせない時：PragmaとCache-Controlのno-cacheを同時に設定
  • キャッシュの有効期限が明確に決まっている時：Expiresを指定する
  • キャッシュの有効期限を相対的に指定したい時：Cache-Controlのmax-ageの相対時間を指定する

参考

個人的には下記の本もわかりやすいと思っています😅