<< URI 設計の例 : 郵便番号と住所 | main | 個人の識別キーの設計 : 名前? 番号? メールアドレス? 別名? >>

URI でリクエストされた時に送るデータの設計



URI は、記述的にわかりやすく設計する。
利用者が欲しいと思っている情報を、直感的に表現した名前が良い URI。

/郵便番号/東京都/文京区/本郷三丁目

で送り出す主なデータは、 "113-0031" 。

path の先頭の要素は、「データの集合」の名前にする


関心事は、「郵便番号」だから、Path も、「郵便番号」ではじめる。そして、送り返すデータは、ストレートに、"113-0031"。

こういう単純明快さが、良い、URI の設計。

path の先頭は「データの集合」の名前にするのが原則。

「郵便番号」というデータの集合から、特定のデータを指定するための仕組みが、URI ということ。

ROA ( リソース指向アーキテクチャ)の発想だとこうなる。

アマゾンは、path の先頭を /本-和書/ とか、使っていますね。本-和書についての「データの集合」を起点に探す。

手続き的というか、機能指向だと、 グーグルのトップページのように、/search になる。
もっとも、個別の検索機能では、

/webhp Web のホームページ
/imghp イメージ情報のホームページ
/maps 地図

という感じで、対象とする「データの集合」の名前が、path の先頭要素になっている。

日本郵便の郵便番号検索のように、プログラミング指向だと、 /cgi_zip/zipcode.php を起点に探すことになる。
アンチパターン。

レスポンスデータの内容


URI の設計がよく出来ていれば、レスポンスデータの内容も、単純に決まるはず。

/郵便番号 であれば、 "113-0031" を返す。
/maps であれば、 指定位置の "地図" を返す。

/本-和書 はちょっと、悩ましい。実際に、アマゾンの場合は、一ページに収まりきらない、膨大なデータが帰ってくる。 私は、ほとんど、目的買いなんで、あんなにたくさんの情報、欲しくないんですけどね。

URI はできるだけ、シンプルで、わかりやすくあるべきだし、返すデータも、できるだけ、シンプルで、わかりやすくするのが良い設計だと思う。

もっとも "113-0031" だけでは、さすがに、シンプルすぎる。

実際の検索サービスでも、”東京都 文京区 本郷 " という 都道府県名、市区町村名、町域名もいっしょに帰ってくる。 町域名は、さらに、「ヨミガナ」も返る。

ページ自体は、パンくずリストがあって、上位の path への リンクとか、いろいろな関連情報へのリンクがてんこもり。

まあ、こういうリンクも、できるだけ目的にそって、厳選して、シンプルにしたほうが良いに決まっている。

アマゾンの本の詳細画面のように、読みきれないほどのデータを、送りつけてくるのは、どうかと思う。

表現の形式


基本の形式は、XHTML 、 XML、 JSON とかかな?

私は、XML がもっとも良いと思っている。データの要素名や構造を適切に表現するには、やはり、XML が一番。

XHTML を、画面レスポンスだけでなく、データのレスポンス形式として、そのまま使う、というアイデアもある。
これだと、画面も、REST サービスも、同じになるので、サーバーの開発側は楽かもしれない。

でも、実際には、 画面を使うシーンで、欲しい情報と、REST サービスで使うシーンで欲しい情報は、違っていることが多い。

だから、XHTML という形式で共通化するメリットを私はあまり感じていない。
クライアント側のソフトウェアを開発することも多いので、 XHTML より、XML でもらったほうが、やりやすいと思っている。

JSON は、手軽といえば、手軽なんだけど、データのメタ情報(項目の名前)とかが、表現されていないので、あまり、良いやり方じゃないと思う。

構造が、 map (連想配列) を使うのが適切な場合は、key の名前で、情報の意味を表現できるかな。

State Transfer ということ


REST は、 ご存知のように、 REpresentational State Transfer から作った造語。

"Representational" が、「表現」ということ。
つまり、「リソース」そのものではなく、その「表現」を返すという発想。

URI にリクエスト内容によっては、異なる表現形式で返すのもあり、というわけだ。
図形的な表現なら、svg のようなベクター形式もありだし、イメージファイル、として表現という手もある。
化学の構造式とかは、XML で表現するボキャブラリセットが、利用されている分野。

注目は、 "State Transfer" のほう。

"State" というのは、状態。 プログラミング的には、変数の集合、データベース的には、カラムの集合ですね。

REST は、リソースの「状態」を、「転送」する、という発想。

状態なんで、もちろん、いつも同じとは限らない。 同じ URI でリクエストしても、そのたびに、違う内容が帰ってくるのが、当たり前の世界。

郵便番号の例だと、 /郵便番号/東京都/文京区/本郷 の URI path で、"113-0033" が変わることはあまりなさそう。

でも、/住所/330-0841 という URI の path だと、昔だったら、「大宮市」が戻ってきて、現在は、「さいたま市」が返ってくる。

「住所」というデータセットは「市区町村の合併」などで、いろいろ変化している。

URI は、「識別キー」だけど、タイミングによって、異なる内容が返ってくる仕組み。つまり、「一意」の識別ではない、ということ。

エンタープライズアプリケーションでは、多くの関心事は、この「変動」する情報。リソースそのものは、 URI で、一意に決まるけど、その「現在の状態」は一意ではない。

「状態の変化」のモデリングと設計のパターン


この変化する「状態」を、うまくモデリングして、設計・実装することが、エンタープライズアプリケーションの中核の課題。

「パターン言語」として、いろいろ、考えていることも、この「状態の変化」のモデリングパターンであり、設計パターンが、いちばんの関心事。

REST の URI/表現のように、「識別キー」を指定すると、「現在の状態」の「表現」を提供する、というのが、まずは基本パターン。

「銀行口座」を指定すると、「残高」を知らせる、というパターンです。

「現在の状態」を提供するためには、「状態を変化」させることが必要。
エンタープライズアプリケーション、事業のためのソフトウェアでは、状態を変化は、誰でも、好き勝手にできるわけではない。

事実を正しく反映しなきゃいけないし、変化させるための、権限とかルールなどの決め事が多いことも多い。
また、「変化」が起きたら、それに反応する必要がある。 「変化の検知」や「変化の通知」も、エンタープライズアプリケーションの重要な関心事。

ここらへんのモデリングパターン、設計・実装パターンをいろいろ書き始めているところ。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM