去年受けた研修で参考図書として挙げられていた本を図書館で見かけたので借りて読んでみた。非常に腑に落ちる良い勉強になった。Web利用者として実体験として経験していたことをしっかりと体系的な解説として勉強できた感じ。基礎的なことなのだが、きちんと学んでいるとのそうでないのは、これからの仕事にも違いがでる気がした。

私的備忘録としてまとめて書きしたものを貼り付けておきます。(HTMLで書いておきたいが面倒なのでpreで、、)

◆Webサービスのアーキテクチャパターン
REST = ULCODC$SS(Unified Layered Code on Demend Client Cache($) Stateless Server)
・Client-Server: ユーザーインタフェースと処理を分離する
・Stateless Server: サーバ側でアプリケーションの状態を持たない (Resourceは持っていい)
・キャッシュ: クライアントとサーバの通信を減らす
・統一インタフェース: インタフェースを固定/限定する
・階層化システム:システムを階層に分離する
・コードオンデマンド:プログラムをクライアントにダウンロードして実行する
+重要な設計ポリシーとしては、
・アドレス加続性:URIによってすべてのリソースを一意に指し示すことができる
・接続性:リソースをリンクで接続して1つのアプリケーションをなす
−現実としては
・Cookieによるセッション管理(非ステートレス)

◆URIの設計
そもそも「URIを設計する」という考え方
クールなURIは変わらない (Cool URIs don't change)
(すなわちそれはファイルディレクトリを整理するのと同じ)
・URIにプログラミング言語依存の拡張子を使用しない(.pl,.rb,.do,.jsp,etc..)
・URIにプログラミング言語のメソッド名を使用しない
・URIにセッションIDを含めない
・URIはそのリソースを表現する「名詞」である
※どうしても変更が必要な場合はリダイレクト(3xx)を利用する

◆設計のためのTips
・ステートレスは、Webサービス/APIをスケールアウトするためのアーキテクチャ
・ステートレスは、WebページにDirectLinkしてもページが成立するとの同じ考え方
 ⇒リソース志向アーキテクチャを実現するには、
  情報アーキテクチャ(IA)のアプローチから良い導出が可能そう
・ステートレスとステートフルでトレードオフとして注意すべきは
 送信データの増加・処理の冗長にともなうパフォーマンスの低下
 通信エラー処理
・トランザクションリソース
 トランザクション用のリソースを用意してそのリソースに対し、
 処理をPOSTし、PUTでSubmit文を投げて実行、終わればDELETEする
・排他リソース
 排他解決用にリソースを用意し、そのリソースの状態によって
 排他状態をクライアントから制御する
⇒なるべくシンプルに保つ
 そして、困ったらリソースに戻って考える
 が基本

図書館利用はもっぱらlibronで狙い撃ちだったのですが、年末年始は時間があったので図書館をうろうろしていたところ、思いがけず良書に出会っています(^^)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
山本 陽平
技術評論社
売り上げランキング: 15881