読者です 読者をやめる 読者になる 読者になる

Jの衝動書き日記

さらりーまんSEの日記でございます。

 Webを支える技術 勉強会まとめ その2

技術 Web

Webサービスに関する基本的な技術を体系的によくまとめている良書、「Webを支える技術」を読み終わったのでメモとしてまとめてみたものの第2弾である。今回はHTTPに関する事項をまとめてみた。とはいえ、自分向きのメモなので、HTTPを体系的に知りたければ、是非この本を読んで欲しい。

3.HTTP

Webを支える重要なアーキテクチャの一つである。ここではポイントだけまとめてみた。

3.1 RESTスタイルのメソッド使用

Webサービスでは、HTTPのメソッドとしてGET、POSTを使用する。RESTスタイルだと、PUT/DELETEも使用する。RESTスタイルのWebサービスでは、リソースに対するCRUD操作(追加・読込・変更・削除)という位置づけなので、使用するHTTPメソッドもこれに対応して、C→POST、R→GET、U→PUT、D→DELETEと利用する。

POSTメソッド

  • 子リソースの作成
    • レスポンスは201 Created
    • 追加したリソースのLocationも帰る
  • リソースへのデータ追加
    • レスポンスは200 OK
    • Locationとかも特には帰らない → 既存リソースへの追加だから
  • 他メソッドの代用
    • パラメータが非常に長いGETの代用等


PUTメソッド

  • リソースの更新 → POSTはこれは出来ない 
  • リソースの作成
    • 存在しないURIへのPUTはリソースの作成となる
    • サーバ側のURI実装を知らないと上手く使えないため、サーバと密結合になるので滅多に使わない

 
ただし、htmlのformの仕様上、使用可能なHTTPメソッドはGETとPOSTだけであるため、PUT/DELETEの使用のためには以下のような一工夫が必要。

3.2 HTTPヘッダのメモ

HTTPヘッダで入力可能な文字はASCIIコードのみ(ISO 8859-1)と規定されている。また、日時はすべてGMTで指定する。HTTPでやりとりするリソースの種類は、MIME:リソースの表現の種類(メールの物と同様)で指定する。

  • Content-Type:メディアタイプの指定
    • メディアタイプ/サプタイプ
    • application/xhtml+xml
    • メディアタイプは勝手に増やせない → RFCで規定
    • サブタイプは比較的自由 → x-は自由に付けられる

text/のメディアタイプのデフォルトエンコード方式は ISO 8859-1と規定しているため、charsetパタメータを指定しないと文字化けを起こす可能性がある。文書の中には文字コード指定していても、charset指定なしだと無視されてしまう。
例)Content-Type: text/plain; charset=utf-8
 

3.3 ステータスコードについて

ステータスコードの分類は以下の通り。

  • ステータスコード
    • 1xx:処理中
    • 2xx:成功
    • 3xx:リダイレクト
    • 4xx:クライアントエラー
    • 5xx:サーバエラー

 
よく使われるステータスコードは以下の通り

  • 200:成功
  • 201:リソースの作成成功 → +Locationヘッダ
  • 301:リソースの恒久的な移動 → +Locationヘッダ
  • 303:別URIの参照
  • 400:リクエストの誤り 
  • 401:アクセス権不正 → + WWW-Authenticateヘッダ
  • 404:リソースの不在
  • 500:サーバ内部エラー
  • 503:サービス停止 → + Retry-Afterヘッダ
3.4 認証方式について

401応答で認証が必要なことと、その情報を通知する。
例)WWW-Authenticate: Basic realm="Example.jp"
realmとは、認証対象が属するURI空間のことで、同じURI空間に属するリソースに関しては同じ認証情報を渡せばよい。

Requestの度にユーザ名とパスワードをBASE64エンコードした上で送信する。認証情報は、Authorizationヘッダに設定する。パスワードは平文で流れる(エンコードは簡単にデコード出来るから)のでSSLとの組み合わせで使用する。

  • Digest認証

ユーザ名、パスワード、その他サーバから通知された認証情報を元にMD5でハッシュ化して送信する。サーバ上に保存するのは、パスワードそのものではなく、パスワードのハッシュ値でよい。サーバ側でパスワード管理する必要が無い点が利点。認証情報は、Authorizationヘッダに設定する。
欠点は、リクエストの度にサーバから401レスポンス経由でダイジェストを貰わねばならない点。そのため、あまりつかわれていない。

  • WSSE認証(WS-Security Extension)

認証情報は、Authorizationヘッダ + X-WSSE拡張ヘッダに設定する。
サーバ側でユーザ名とパスワードを保存し、クライアントから送信されたnonce(リクエスト毎に変化する文字列)を元にハッシュ値を計算して認証する。Digest認証と異なり、サーバ側からは認証に必要な情報(nonce等)は送信しない。

3.5 リソースキャッキュについて

リソースのキャッシュ方法はヘッダで指定する。

  • Pragma:キャッシュを抑制
  • Expires:キャッシュの有効期限を示す
  • Cathe-Control:キャッシュ方法を指定。PragmaやExpiresの代用も可。有効期限は、絶対時間だけでなく、相対時間でも可

リソースのキャッシュを有効に使用するには、条件付きリクエストを送信する。更新日時を過ぎていたら取得するなど。

  • If-Modified-Sinceヘッダ

リソースの更新日時を条件にGETする。更新時間を過ぎていないと、304 Not Modifiedが返る。GETの応答時に、 Last-Modifiedヘッダに最終更新時間を渡す必要がある。

  • If-None-Matchヘッダ

リソースのETagを条件にGETする。ETagが不一致だとGETする。GETのレスポンスでETagを返す必要がある。

参考文献

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)