decode

技術ブログ 本の紹介

webを支える技術 読みました

webを支える技術を読みました。

Webを支える技術 ── HTTP,URI,HTML,そしてREST(WEB+DB PRESS plusシリーズ)|gihyo.jp … 技術評論社

webを支える技術を読みました。

Naclの今の担当の方に「これ呼んだらいいかも!」って言われたからです、
なかなか勉強になりました。

アーキテクチャスタイル

複数アーキテクチャに共通する性質、思想。
例としてはMVC、Pipe and Filter、EventSystemなど。
実際のシステムはアーキテクチャを持っているが、そのアーキテクチャのもう一つ抽象版。
デザインパターンの様なモノ
実装から一つ上の抽象度がアーキテクチャで、そのもう一つ上がアーキテクチャスタイル。

REST

RESTとは、クライアント/サーバシステムのアーキテクチャスタイルの事。
つまり実装ではなく、こうあった方がいいよね、ってお話。

重要概念 リソース

Webにおけるリソースというのは、「Web上のあらゆる情報」のこと。
名前をもつというのは、あるリソースと他のリソースを区別して指し示すためのものである。

http://practical-scheme.net/wiliki/wiliki.cgi?naoya_t%3A%E3%83%9D%E3%83%BC%E3%83%AB%E3%83%BB%E3%82%B0%E3%83%AC%E3%82%A2%E3%83%A0%E3%81%AE%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4%E3%81%A8%E5%92%8C%E8%A8%B3%E4%B8%80%E8%A6%A7

http://xn--97-273ae6a4irb6e2hxjpb5etb3nqtgfpmg22065a.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4

  • ソフトウェアアーキテクトが知るべき97のこと

http://xn--97-273ae6a4irb6e2h2ia0cn0g4a2txf4ah5wo4af612j.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4


世界中のリソースはURIで一意の名前を持つ。
URIを使うと、プログラムは情報にアクセスできる。

一つの情報に複数URIを付けることも可能。
その場合クライアントがリソースにアクセスしやすくなる(数がおおいから)が、どれが正式なURIか分からなくなる。

サーバとクライアントの間で実際にリソースをやりとりする事をリソースの表現という。
一つのリソースは複数のリソース表現をもてる(HTMLをやりとりしてもいいし、PDFでも、画像でも)

RESTとは? RESTが課す制約

1. クライアント・サーバ

クライアントがサーバにリクエストを送り、サーバはクライアントにレスポンスを返す。

クライアントとサーバに分離して処理ができる、
クライアントがマルチプラットフォーム化できる。(PCでもPSPでもガラケーでも)
ユーザインタフェースはクライアント担当なので、サーバはデータストレージ的な機能で良くなる。
複数のサーバを組み合わせて冗長化する事で可用性が上がる。

2. ステートレスサーバ

サーバがクライアントの状態を把握しない設計。
ハンバーガー屋さんみたいなイメージ。買ったら知らんみたいな。
ステートフルは茶碗にご飯がなくなった時についでくれるいいお嫁さんみたいな感じ

実装が用意になり、リクエストに答えた後はサーバの計算機リソースを開放できる。

ステートフルの代表は、Coocieなど、
クライアントサーバにステートレスを追加すると、「クライアント/ステートレスサーバ」と呼ぶ。
(Client Stateless Server, CSS)

3. キャッシュ

リソースの鮮度に基づいて一度取得したリソースをクライアントで使い回す事

サーバとクライアント間の通信が減る。
ただし、古いキャッシュを利用してしまい、情報の信ぴょう性が下がる可能性を意識しないといけない。

キャッシュを追加すると、「クライアント/キャッシュ/ステートレスサーバ」と呼ぶ
(Client Cache Stateless Server, C$SS)

4. 統一インタフェース

URIで指定したリソースへの操作を統一したインタフェースで行う事。
例えば、HTTP1.1ではGET,POSTなどのような8つのメソッドのみで(統一)通常拡張できない。

インタフェースを制限する事により、シンプルになり、クライアントとサーバの実装の独立制が上がる。

統一インタフェースを追加すると、「統一/クライアント/キャッシュ/ステートレスサーバ」と呼ぶ。
(Uniform Client Cache Stateless Server, UC$SS)

5. 階層化システム

統一インタフェースを使う事でシステムが階層化しやすくなる。

例えば、サーバとクライアントの間にロードバランサを置いても、プロキシを置いても接続の際に気にし無くてよい。
これは各コンポーネント間をHTTPで統一しているから。

階層化システムを追加すると、「統一/階層化/クライアント/キャッシュ/ステートレスサーバ」と呼ぶ。
(Uniform Layered Client Cache Stateless Server, ULC$SS)

6. コードオンデマンド

プログラムをクライアントにダウンロードし、実行できる様にすること。
例えば、JSやFlash,Javaアプレットが該当する。

利点としてはクライアントを後から拡張できる事。
欠点としては通信の意味やアクセスするリソースが明白でなくなる事(ダウンロードして実行するため)

コードオンデマンドを追加すると、「統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ」
(Uniform Layered Code on Demand Client Cache Stateless Server, ULCODC$SS)↲

REST = ULCODC$SS*

RESTと言うのは6つのアーキテクチャスタイルを組み合わせたモノである。
RESTはアーキテクチャスタイル(理想)なので適用を妥協する場合もある。(P2P通信など)

RESTでは、リソースのURIを通してアプリケーションを構成する。

認証

Basic認証

Basic認証はユーザ名とパスワードによる認証。

DELETE /test HTTP/1.1
Host: example.jp
Authorization: Basic DBNLcjpYXNzd29yZA==

Authorizationヘッダの内容は、認証方法: ユーザ、パスワード。
Base64エンコーディングは簡単にデコードできる。(もはや平文)

Digest認証

Digest認証はあるメッセージに対して
Digest認証でも、クライアントはまず、認証情報なしでリクエストを送信する。

DELETE /test HTTP/1.1
Host:example.jp
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Example.jp", nonce="f9oe98fua89fue9ofu89oaf89", 
qop="auth", opaque="93d8u8xtxfeyx3ge8u62b9ibc"

WWW-Authenticateヘッダの値を「チャレンジ」という。
「nonce」はnumber used once の略で、リクエストごとに変化する文字列。
生成するハッシュ値をよりセキュアにするために利用する。
「qop」はquality of protectionの略で、authかauth-initを指定する。
authはメソッドURIからダイジェストを生成する。
auth-initはメッセージボディも含めてダイジェストを生成する。(POSTやPUTの際に良い)
opaqueは、クライアントには不透明(推測できない)文字列で、同じURI空間へのリクエストでは、クライアントからサーバに送る。

サーバから認証に必要な情報を得たクライアントは、ユーザ名とパスワードを使って、ダイジェストを作成する。

  1. ユーザ名、realm、パスワードを:で連結し、MD5(Message Digest Algorithm5)ハッシュ値を求める。
  2. メソッドURIのパスを:で連結し、MD5ハッシュ値を求める。
  3. 1の値、サーバから得たnonce、クライアントがnonceを送った回数(0000001など)、

クライアントが生成したnonce、qopの値、2の値を:で連結してMD5ハッシュ値を求める。

再度クライアントはリクエストを送り、認証が成功して削除も成功すると200 OKがレスポンスされる。


Digest認証ではパスワードを盗まれる危険性がなく(盗まれても大丈夫である)、サーバ上に保存される値はパスワードのハッシュ値であるため、セキュアになる。
ただし、 Digest認証はパスワードを暗号化するだけなので、メッセージ自体は平文で送られる。メッセージも暗号化したい場合にはHTTPSを使うべき。

Basic認証では一度認証してしまえば自動でユーザ名パスワードを送れるが、DIgest認証ではサーバnonceがないとダメなのでリクエストのたびに401 Unauthorized レスポンスを得ないといけない。

WSSE認証

WSSE認証はHTTP1.1標準外認証方法。
SSLTLSが利用できないためBasic認証が使えず、Digest認証も使えない時にrawパスワードを送りたくない際に開発された。
WSSE認はパスワードは暗号化されるうえ、Digest認証ほどの面倒さもない。サーバ側では生のパスワードを保存しておく必要があるなど、Basic認証とDigest認証の中間に位置する。

ヘッダ種類

キャッシュ

Pragma --キャッシュの抑制
Pragma: no-cache

no-cacheしか指定できない。毎回サーバにアクセス。

Expires --キャッシュの有効期間
Expires: August, 26 sun 2010 16:00:00 GMT

この日まではキャッシュは新鮮である。

Cache-Control --詳細なキャッシュ方法の指定
Pragma: no-cache
Cache-Control: no-cache //こう書ける

Cache-Control: max-age: 86400  // 現在から24時間

みたいな。

条件つきGet

If-Modfied-Since --リソースの更新日時を条件にする。
GET /test HTTP/1.1
Host: example.jp
If-Modified-Since: Thu, 11 May 2010 16:00:00 GMT
HTTP/1.1 304 Not Modified
Content-Type: application/xhtml+xml; charset=utf-8
Last-Modified: Thu, 11 May 2010 16:00:00 GMT

304 Not Modifiedは条件付きGETレスポンスで、サーバ上のリソースを変更していない事を知らせるステータスコード












疲れたのでこのへんで、

広告を非表示にする