Jの衝動書き日記

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

トップ > 技術 > 　Webを支える技術　勉強会まとめ　その２

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

技術 Web

Webサービスに関する基本的な技術を体系的によくまとめている良書、「Webを支える技術」を読み終わったのでメモとしてまとめてみたものの第２弾である。今回は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)