<< 「知りたいこと」を提供する 【パターン】 | main | URI 設計の例 : 郵便番号と住所 >>

たかが URI の設計、されど URI の設計

関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。

 GET /リソースの識別名(URI)

をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。

ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「URI」を「識別キー」という言葉にしている。

実際に、HTTP を使うかどうかは別として、

◎ リソース(=関心事オブジェクト)の
◎ URI (=識別キー) を指定して
◎ 現在の状態(current state)を入手する

というのは、エンタープライズアプリケーションの基本価値のひとつですね。
「関心のあることを知る」という業務の基本ニーズ。

このニーズに応えるための GET 方式のモデリング・設計は、エンタープライズアプリケーションのモデリング・設計の基本になる。

GET 方式の情報入手のモデリングと設計には、RESTful web サービス の考え方が、とても参考になる。
私の考え方も、この本に強く影響を受けている。

特に、URI (識別キー)の設計は、

4章 リソース指向アーキテクチャ
 4.3 URI
  4.3.1 URIは記述的であるべき

5章 リソース指向サービスの設計
 5.5 リソースに名前をつける
  5.5.1 階層パス
  5.5.2 カンマまたはセミコロン

あたりが参考になる。

内容をかいつまんで、紹介してみます。

URI ( 識別キー ) は記述的であるべき


この本の例。

http://www.example.com/relationship/Alice;Bob ( アリスとボブの関係は?)
http://www.example.com/sales/2004/Q4  (2004年、第4四半期の売上は?)
http://www.example.com/bugs/by-state/open (未解決のバグは?)
...

こんな感じで、「知りたいこと」をそのまま、表記する、というのが、この本の主張です。

example.com 社の公開リソース(www) の例ですね。

社内(イントラ)の業務システムなら、

http://intra.system-sekkei.com/customer/contactinfo/masuda220 (masuda220 の連絡先は?)
http://intra.system-sekkei.com/project/by-state/on-going (実施中のプロジェクトは?)
http://intra.system-sekkei.com/human-resource/skillset/masuda220 (masuda220のスキルセットは?)
...

こんな感じになる。

クエリ文字列方式


クエリ文字列、たとえば、 find?id=masuda220&infotype=contact との違いに注目。

この本は、クエリ文字列は、否定はしていない。しかし、パラメータ名は、"SHOW" とか、特定の名前、汎用的な名前に限定するという考え方。

REST スタイルでは、基本コマンドは、事前定義された、GET/PUT/DELETE/POST に限定している。
この考え方を延長すると、クエリ文字列のパラメータ名も、よく使われる汎用的な名前に限定する、という発想になる。

設計課題は、URI (識別キー)


REST スタイル、あるいは、リソース指向では、いちばんの設計課題は、リソース(=関心事オブジェクト)の、識別キーを設計すること。

逆に、「コマンド(=処理命令)」は、REST スタイルでは、設計課題ではない。
必要最小限の well known のコマンドセットが事前に定義されているから。

SQL文でも、コマンドは、 select/insert/update/delete に限定している。

リソース指向やデータ指向だと、機能(コマンド)は、最初から決まっている、という考え方。
その視点からは、クエリ表現は、 URI の設計ではなく、コマンドの設計、という捉え方なんですね。

/find?id=masuda220&type=contact&format=xml

find( id, type, format ){}
というメソッドの設計をそのままだから、リソースの識別キーを設計する、という発想とは、別の考え方だよ、ということ。

リソース指向で、エンタープライズアプリケーションすべてをモデリングして設計することが良いのか、わからないけど、「関心事オブジェクト」の「現在の状態」を取得する、というニーズのモデリング・設計には、REST スタイルの GET 方式、つまり、URI(識別キー)の考え方が、ぴったりくると思っている。

階層パス、コンマ区切り、セミコロン区切り


5章の「リソースに名前をつける」も興味深い。

階層パス


これは、見慣れていますね。
/main/sub/sub-sub/sub-sub-sub/...
という階層構造で詳細化していく。

ツリー構造。
ファイル管理では、一般的なやり方ですね。

しかし、世の中、すべてがツリー構造で整理できるわけではない。
「階層」にすることが不自然なケースも多い。

ソフトウェアの開発をしていると、ディレクトリ構造、クラスパス、URL、...というように、木構造にどっぷりつかっている。

ただ、なんでもかんでも、ツリーで表現しようとすると、あちこちで不自然で、ぎこちないことが発生する。

コンマ区切りの列挙、セミコロン区切りの列挙


本の例から...

/position?latitude=36.313&longitude=124.234
よりも
/position/36.313,124.234


/colorpair?color1=red&color2=blue
よりも
/colorpair/red;blue

/articles?start=20061201&end=20071201
よりも
/articles/20061201-20071201

のほうが、わかりやすい(自然な記述)でしょ、という考え方。

コンマ区切りは、順番を表現したい場合 ( List だな )。
セミコロン区切りは、順番に意味がない場合 ( Set だな )。

from-to は、ハイフン区切りが自然。

できるだけ、日常の表現形式にあわせた URI 表記が良いといっている。

もっと、記述的に


まあ、普通の技術者は、?start=20060701&end=20061201 でも、わかりやすいと思うかな?

この本の考え方の本質は、もっと別のところにあると思う。

たとえば、期間を限定する方法として、 from-to ペアは、とてもなじみがあるやり方。
この機能を実現すれば、どんな、期間指定でもOK、というのが技術者の発想。

でも、実際の業務は、from-to ですべてやっているわけではない。

/sales/today
/sales/yesterday
/sales/thisweek
/sales/lastweek
/sales/thisyear
/sales/lastyear
...

という感じ。
もちろん、内部的には、from-to ペアの検索の仕組みを使えば、それでOK。

重要なのは、「関心事」の「識別キー」として、汎用的な from-to ではなく、

today
yesterday
thisweek
thisyear
...

という、もっと、記述的な表現のほうが、業務のニーズ、感覚にあっている、ということ。
事業の関心事、業務の関心事は、form=YYYYMMDD to=YYYYMMDD という形式ではなく、「今日」とか「今月」とか「今期」で表現するのが自然。

まあ、ユーザが、from-to ペアを希望することもあるけど、実際には、today とか thisweek のほうが、業務の関心事であることが普通だと思う。

内部の仕組みとして from-to ペアが有用でも、使う側から見た、業務の道具として、from-to ペアが良い識別方法とは限らない。

ここらへんの気配り、検討が、アプリケーションソフトウェアの分かりやすさ、使いやすさに大きく影響する。

URI (識別キー)の設計といっても、奥が深いし、どういう設計にするかは、「関心事」の把握・理解と直結しているわけです。

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