^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          summary
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

3部 HTTP
  • HTTPの基本
  • HTTPメソッド
  • ステータスコード
  • HTTPヘッダ

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

6章.HTTPの基本


HTTPはステートレスなプロトコルとして設計されている。

ステートフル利点

新規に必要な情報である差分のみをやりとりするので簡潔。

ステートフル欠点

各ユーザの状態を記憶するので複数のサーバで複数のユーザに対応する際、各ユーザの状態をサーバごとに同期する必要がありオーバーヘッドが大きい。

ステートレス利点

必要な情報を毎回繰り返しやりとりするので冗長。

ステートレス欠点

サーバは各ユーザの状態を記憶する必要がないので、新規に来るリクエスト一回に集中するだけで良く、サーバ側の処理が簡素にな。

Webの利用形態は不特定多数を前提としているので、全ユーザの状態を覚えるのは難がありそうですね。なので冗長なデータなどはHTTPヘッダなどで明示し、クライアント側でキャッシュするよう工夫されているのですね。この辺の話は9章辺りに詳しく書かれています。

7章.HTTPメソッド


POSTとPUTの使い分け

両者ともリソースの作成ができるが、POSTで作成したリソースにアクセスするURIはサーバが決定する。PUTで作成したリソースはユーザ自身がURIを決定する。TwitterのようにつぶやきのURIを自動的に決定するサービスはPOST、Wikiのようにユーザ自身がタイトルを決定する場合はPUTを使う。尚、POSTの場合は自動でサーバがURIを決定するのでレスポンスとしてLocationヘッダを返すと良い。クライアントがリソースを決定できるPUTはクライアントがサーバの内部実装を熟知する必要があるので結合が密になる。特別な理由がない限りは、リソースの作成はPOSTで行い、URIはサーバ側で決める設計が望ましい。

_methodパラメータ

_methodパラメータをフォームの隠しパラメータするとPOSTPUTDELETEの代用ができる。(GETPOSTだけの制限をかけているサーバもわりと多い)

べき等性と安全性
  • べき等性 : ある操作を何回行っても必ず同じ結果である。(リソースの内容が更新されている、削除されているなど)
  • 安全性  : 操作対象のリソースの状態を変化させない。
HTTP method   性質
GET べき等かつ安全
PUT、DELETE   べき等だが安全でない
POST べき等でも安全でもない

^^

べき等の性質を持つHTTP methodは、通信エラーなどによる送信の重複を恐れる必要はない。一方、べき等でないPOSTはダイアログで警告を促すなど工夫しなければ二重注文などが発生する可能性がある。べき等などの性質はHTTPの仕様に定められており、性質通りにHTTPメソッドを使用するべきである。 例えばPUTで数値を50ずつ更新するようなリクエストは更新のたびにリソース値が変化するため、べき等ではなくなる。このような場合は差の50でなく、合計値への更新をリクエストすべきである。

8章.ステータスコード


Acceptヘッダに応じたフォーマットでエラーレスポンスを返すと親切。

9章.HTTPヘッダ


MIMEメディアタイプ

XMLのように文章本体で文字エンコーディングを指定できる場合であっても、charasetヘッダを省略するとtextタイプの文字エンコーディングが指定されてしまうため、必ずcharasetで明示的にエンコードタイプを指定する事。合わせてContent-Typeでメッセージのボディーのメディアのタイプも指定するべき。

コンテントネゴシエーション

クライアントはAcceptAccept-Charset,Accept-Charset, Accept-Languageなどのヘッダをリクエストヘッダに付加することで、指定した条件でレスポンスを受け取る事ができる。

Content-Lengthとチャンク転送
  • content-Length    : 静的ファイルなど、予めサイズのわかっているリソースを転送する際に使用する。
  • Transfer-Encoding  : chunkedと指定することにより最終的なサイズの分からないボディを少しずつ転送可能にする。
キャッシュ用ヘッダ
  • pragma     : no-cacheを指定しキャッシュしてはならない事を知らせる。(リソースの取得は必ずサーバにアクセスする必要がある)
  • Expires     : 絶対時間を指定し、時間内はリソースが最新であることを知らせる。(時間内はクライアントはリソースをキャッシュする)
  • Chache-Control : 相対時間を指定し、時間内はリソースが最新であることを知らせる。その他に高機能なキャッシュ制約を指定できる。
キャッシュ用ヘッダの使い分け
  • キャッシュをさせない場合は、pragmaChache-Controlを同時に指定する。
  • キャッシュの有効期限が明確に決まっている場合は、Expirsを使用する。
  • キャッシュの有効期限を相対的に指定したい場合は、Chach-Controlmax-ageで相対時間を指定する。
条件付きGET

pragma, Expirs, Chache-controlはサーバ側からクライアント側のレスポンスにて使用されるのに対し、If-Modified-Since, If-None-Matchはクライアント側でキャッシュしてあるリソースが変更されているかを調べる条件、手段をサーバ側に提示し、キャッシュ可能かを検証するヘッダである。またIf-Modified-Since, If-None-MatchはリソースがLast-ModifiedまたはETagを持っている時に使用可能である。

  • If-Modified-Since : リソースの更新日時を指定し、指定時間以降に更新がない場合は304 Not Modifiedを返す。
  • If-None_Match   : キャッシュしていあるリソースのEtag値(gitのハッシュ値のようなもの)を指定し、サーバ側のリソースのETag値と比較する。同じであれば304 Not Modifiedを返す。(時計をもっていないサーバやミリ単位で変更される可能性のあるリソースを扱う際に有効)
If-Modified-Since、 If-None-Matchの使い分け

サーバ側を実装する場合はキャッシュ可能なリソースにはできるだけEtagを使用する。




comments powered by Disqus


© 2015 kyuden