resource-design

WebサービスとWeb APIを相互活用する リソース設計の方法

前回は、ブログやSNSなど書き込み可能なWebサービスの設計について、郵便番号検索サービス設計を通してまとめた。ここでは、WebサービスとWeb APIを相互活用するといったリソース設計の方法についてまとめる。

1 リソース指向アーキテクチャのアプローチの落とし穴

リソース指向アーキテクチャの設計アプローチの落とし穴は、「Webサービスで提供するデータを特定」し、「データをリソースに分ける」方法がわからないことである。

ここでは、ある程度確立されている既存の設計手法で得られた成果物を基にリソースを設計する方法を解説する。対象とする成果物は、以下の3つである。

  • 関係モデルのER図
  • オブジェクト指向モデルのクラス図
  • 情報アーキテクチャ

 

2 関係モデルからの導出

関係モデル(Relational Model)はRDBMSの基礎となっているデータモデルであり、数学的基盤を持っていることが特徴である。データの冗長性を排除するための正規化の手法が確立されており、効率的なデータベース設計ができる。

 

郵便番号データのER図

ER図には3つのテーブルがある。郵便番号テーブルは、郵便番号とその郵便番号が示す町域名とそのフリガナを持つ。都道府県テーブルと市区町村テーブルは、それぞれの名前とフリガナを持つ。

 

中心となるテーブルからのリソースの導出

関係モデルからのリソース抽出の1つの定石は、中心となっているテーブルの1行を1リソースとすることである。テーブルの行をリソースに切り出した場合は、そのテーブルの主キーをURIに組み込むと実装が簡単になる。

 

リソースが持つデータの特定

まず、その中心となったテーブルが持っている属性をリソースに持たせる。次に、そのテーブルが外部キーで参照している別のテーブルもたどり、その属性も郵便番号リソースに持たせる。リソースの設計では、一つ一つのリソースをそれ自身ですべてを表現できるように自己記述的にするために、あえて正規化を崩す。

 

検索結果リソースの導出

検索結果リソースは、このデータベースから具体的に何を検索したいのか、というユーザの利用シナリオに基づいて導出する。

 

階層の検討

階層を検討すると、結果として階層そのものがリソースになることが多い。

 

トップレベルリソース

トップレベルリソースとは、他のリソースへリンクする大本となるリソースで、ER図からは直接導出できない。

 

リンクによる結合

リソース間を結合するリンクの設計にはER図の関連が利用できる。

 

まとめ

関係モデルからリソースを導出する場合は、データの持つ階層構造を考えることと、トップレベルリソースの存在を忘れないことが重要である。

 

3 オブジェクト指向モデルからの導出

オブジェクト指向設計は対象システムの分析モデルを、オブジェクト指向言語のクラスとインスタンスに対応づける。オブジェクト指向設計の成果物としては、クラス図やシーケンス図がある。

 

郵便番号データのクラス図

郵便番号データのクラス図には、5つのクラスが登場する。郵便番号情報を表現するZipcodeクラスと、それぞれ都道府県、市区町村、町域の名前とフリガナを保持するPrefectrue、City、Townクラス。さらに郵便番号全体を管理するZipcodeManagerクラスである。これらのクラスは階層構造を持ち、下位のクラスのリストへの参照と、上位のクラスへの参照を持つ。

 

主要データクラスからのリソースの導出

まず、主要なデータを表現しているクラスを見つける。この主要なデータを表現しているクラスのインスタンス一つひとつが、それぞれURIを持ったリソースとなる。

 

オブジェクトの操作結果リソース

リソースはあくまでも処理結果であることを注意する。

 

階層の検討

階層関係はリソースのURI構造に反映できる。URIの各階層はそれぞれ地域リソースになる。

 

トップレベルリソース

オブジェクト指向モデルにもトップレベルリソースを直接表現するクラスはないため、別途意識して導出する必要がある。

 

リンクによる結合

リソースそのものを表現するオブジェクト(Zipcodeや検索結果のリストなど)は相互に参照を持ち、そのままリンクとして表現できる。

 

まとめ

オブジェクト指向モデルからリソースを導出するときに重要なのは、クラスの持つメソッドを操作結果リソースへと変換することである。

 

4 情報アーキテクチャからの導出

情報アーキテクチャ(Information Architecture)とは、知識やデータの組織化を意味し、「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術である(Wikipediaより)。

 

日本郵便のWebサイトの情報アーキテクチャ

例として日本郵便の郵便番号検索サイト(http://www.post.japanpost.jp/zipcode/)を利用する。

 

トップページ

日本郵便のサイトのトップページには検索方法として、以下の3つが用意されている。

  • 全国地図からの検索
  • 住所での検索
  • 郵便番号での検索

 

全国地図からの検索

全国地図から都道府県名のリンクを選択すると、五十音順に市区群が並んだページに移動する。市区群のページは市区町村のページと対になってリンクしており、市区町村のページに移動して戻れるようになっている。

 

住所での検索

住所での検索を利用するには、プルダウンで都道府県名を選択し、住所の一部を検索フォームに入力する。

 

郵便番号での検索

郵便番号での検索も、同様に検索フォームに郵便番号を入力する。

 

パンくずリスト

パンくずリストによって市区町村から上位の都道府県に戻れるようになっている。

 

まとめ

よく設計された情報アーキテクチャを持つWebサイトの構造は、ほぼそのままWebサービスに適用できる。これは、情報アーキテクチャとリソース指向アーキテクチャが相互に補完関係にあるからである。

 

5 リソース設計で最も重要なこと

ここではリソースの設計について検討し、既存の3つの手法(関係モデル、オブジェクト指向モデル、情報アーキテクチャ)からリソースを導出する方法をまとめた。特に、情報アーキテクチャはリソース設計と相性がいいことがわかる。

 

最後に

郵便番号を検索しよう 読み取り専用Webサービスの設計でも述べたように、リソースを設計するときにはWebサービスとWeb APIを分けて考えないことが重要である。主な対象が人かプログラムかの差はあるが、両者は相互に活用し合えるのである。

17回にわたって、山本陽平著『Webを支える技術』(技術評論社)をまとめ、実践的なWebサービスの設計指針を理解した。著書ではより丁寧な説明に加え、付録としてステータスコードやHTTPヘッダ一覧、そして解説付き参考文献についても簡潔にまとめられている。「Webらしい」Webサービス設計を行おうとする人は、必須の著書であろう。

「未来を予測する最善の方法は、自ら未来を創ることだ」—Alan Kay

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB DB PRESS plus)


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>