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

Webサービスに関する基本的な技術を体系的によくまとめている良書、「Webを支える技術」を読み終わったのでメモとしてまとめてみたものの第４弾である。今回で最終回だ。今回は、本書の目玉とも言えるリソース設計についてまとめてみた。と、いいつつ、いつものように、自分向けのメモなので、興味がある方は是非本を読んで欲しい。

リソース設計

リソース設計とは、クライアントとサーバのインタフェース設計、つまりはWebサービスやWebAPIの外部設計のことである。その設計のアプローチは以下のようになる。

Webサービスで提供するデータを特定する
データをリソースに分ける
リソースにURIで名前を付ける
クライアントに提供するリソースの表現を設計する
リンクとフォームを利用してリソース同士を結びつける
イベントの標準的なコースを検討する
エラーについて検討する

上記で一番重要で、かつ難しいのは、リソースに分けるところである。コツとしては、サービスが扱う対象のデータがリソース候補となるのは当然だが、機能の実行結果もリソースととらえることだ。例えば、検索の場合は検索結果がリソースとなる。

リソース指向アーキテクチャ

リソースの特定作業は、主リソースの導出、機能の実行結果の導出（検索結果等）、リソースの階層構造による導出（階層そのものがリソースになることもある）、リソースのリンク構造の導出などがある。これらリソースを特定する作業として、主に以下の３つの手法がある。

E-R図

リソースをE-R図から特定する。そのため、最初に作成する対象のE-R図を作成する必要がある。
リソース候補としては、システムの中心となっているテーブルの一行を一リソースとする。この場合、そのテーブルの主キーをURIに組み込むことになる。また、テーブルが持っている属性は、そのままリソースに持たせるように設計する。
注意点としては、外部キーがある場合、正規化をあえて崩し、テーブルを結合して必要なデータすべてをリソースに集中するように設計する必要があることだ。リソース設計は、Webサービス・WebAPIの外部設計であるため、相手が必要とする情報は外部キー自体ではなく、それが示す情報そのものであるためだ。
E-R図を使用する利点としては、リソースのリンクによる結合を特定する時、E-R図の関連がそのまま利用出来ることである。逆に苦手とするのは、階層構造の検討だ。

クラス図

リソースをクラス図から特定する。E-R図と同様クラス図をまず作成する必要がある。
リソース候補としては、システムの中心となるデータクラスをリソースとする。この場合、クラスの１インスタンスが１リソースとなる。また、クラスが持つ属性は、そのままリソースに持たせるように設計する。
また、クラスの実行結果（検索結果等）もリソース候補とする。更にオブジェクトの階層関係がリソースの階層となるかを検討する。
E-R図と比べると苦手とするところはないが、そもそもクラスの特定作業が困難だったりする（オブジェクト指向においても、そもそも何をオブジェクトとするのは悩ましい作業だ）。

情報アーキテクチャ

知識やデータの組織化を意味し、情報をわかりやすく伝え、受け手が情報を探しやすくするための表現技術である・・・らしい。必要な情報を上手く構造化して整理したWebサイトと言えばよいのだろうか。発展途上中の設計手法であるとのことだ。

RESTスタイルのトランザクション管理と排他制御

REST FullのWebシステムの場合、ステートレスであるため、アプリケーションの実行状態等の情報は持てない。では、トランザクションを扱うにはどうすればいいかと言うと、トランザクション情報を表現するリソース、トランザクションリソースを用いることになる。流れは以下のようになる。

POSTでトランザクションを作成
PUTで作成したトランザクションリソースの下に追加・変更・削除するリソースを追加
トランザクションリソースへcommitをPUTする

トランザクションリソースは、アプリケーションの状態ではなく、リソースの状態なのでREST Fullという点がポイントだ。

また、リソースの排他制御方法としては、主に以下の２点がある。

悲観的ロック(Pessimistric Lock)

データベースでお馴染みの（SELECT〜FOR UPDATE）予め更新ロックをかけてからリソース更新という方法だ。
RESTスタイルの場合、WebDAVで定義されている、LOCK/UNLOCKメソッドを使用し、対象のリソースを指定する。
もしくは、ロックを表現するリソースを作成することで、同等の機能を実現する。

楽観的ロック(Optimistic Lock)

競合が起きた場合のみ対処するという手法だ。条件付きPUT/DELETEで、もし対象のリソースが更新されていなかったら更新するというアプローチを取る。
具体的には、GETでE-Tagを指定し、それが更新されていなかったら実行する。If-Match/If-Unmodifined-Sinceヘッダを使用し、更新されていたら、412 Precondition Failedが返る。