<< たかが URI の設計、されど URI の設計 | main | URI でリクエストされた時に送るデータの設計 >>

URI 設計の例 : 郵便番号と住所

「住所」を例に、関心事オブジェクトの 識別キー(URI) 設計の例。

日本郵便の郵便番号検索を参考にしてみた。
http://www.post.japanpost.jp/zipcode/

URI のおさらい


URI は、ネットワーク上の資源(リソース)を特定するための、

Scheme : "http:"
Server : "//www.post.japanpost.jp"
Path : "/zipcode/"
Query : ?name=value
Fragment : #ページ内のブロックのid

という構造の識別方式。

「知りたいと思っていること」を、この形式で、どうやって、表現するのが使いやすいサービスだろう?

日本郵便の実際のサイトの Path と Qeury を参考にしながら、リソース指向アーキテクチャ(ROA)っぽい、URI 設計にチャレンジしてみる。

path 名は、日本語のほうが、わかりやすいので、今回は、日本語でやってみます。

path のroot


現状は、 /zipcode になっている。

このリソースを要求すると、「郵便番号検索」のメイン画面がでてくる。
よく見ると、2種類のサービスがある。

ひとつは、「住所」から「郵便番号」を探すサービス。
もうひとつは、「郵便番号」から「住所」を探すサービス。

正引きと逆引きですね。

というわけで、そもそも、ルートが2つ必要。

/郵便番号 (これ以下に、郵便番号リソースがどさっとある)
/住所 (これ以下に、住所リソースがどさっとある)

"/郵便番号"を起点に特定していく


「郵便番号」を知りたい、という要求に、日本郵便が提供しているサービスは、「都道府県」と「市区町村」で調べていく方法。

実際の画面では、 /郵便番号 の要求に対して「都道府県の一覧」を、地図とドロップダウンリストで「表現」している。

xml 形式のレスポンスなら、<prefecture id=13>東京都</prefecture>形式の要素を、47個、ならべる。

"/郵便番号" だけで要求すると、レスポンスは「都道府県の一覧」というわけだ。

都道府県まで指定したリクエスト


/郵便番号/東京都

もちろん、レスポンスは、東京都下の「市区町村」の一覧。
さらに市区町村を指定する。

/郵便番号/東京都/文京区

これで「町域」の一覧がでてくる。 ○○町一丁目 というのが多い。
(番地ではなく、「丁目」まで)

郵便番号サービスで、面白いのは、郵便番号が同じであれば「丁目」は表示せず、郵便番号を特定する時に、「丁目」まで意味がある場合は、「丁目」まで表示する。

この設計、どうなんだろう?
利用者は、郵便番号の体系とかルールとか知らないので、町域が「丁目」まであるのと、ないのが混在しているのは違和感がある。

全部「町域」は「丁目」レベルまで、というほうが自然だと思う。

まあ、実際の画面に合わせて、町域を指定する。

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

めでたく 「113−0033」にたどり着く。
もっとも、本郷二丁目や三丁目という表示はなく、単に「文京区本郷」だけ。
こちらは、「本郷三丁目」まで、住所を知っていて、郵便番号を探しているので、「文京区本郷」だけの表示だと、正しい郵便番号にたどり着けたか、ちょっと不安になる。

実際の URI


以上のケースの実際のサービスの URI は、

/cgi-zip/zipcode.php?pref=13&city=1131050&id=47742

意味不明。

「URI は記述的にわかりやすく!」に徹底抗戦した見事なアンチパターン。

まず、cgi-zip から、始める。 cgi という仕組みから辿れ、というわけだ。

pref=13 が、呪文のはじまり。まあ、都道府県のJISコードなんだけど、意味は不明。
php という、プログラミング言語まで、指定するのが、郵便番号を知るための、お約束?

city=1131050,id=47742 になると、なにをかいわんや。

画面で誘導するからいいや、ということではなく、やっぱり、URI は、「記述的」で「わかりやすく」しておきたい。

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

ってやると、

"東京都文京区本郷三丁目の郵便番号は、 113-0033 です”

という、設計だと、わかりやすでしょ?

良い URI 設計というのは、こういうものなんだと思います。

"/住所"を起点に特定していく


郵便番号から、住所を調べる場合。

実際のサービスは、テキストフィールドで、「最低3ケタ、最大7桁の数字」を入れるという仕様。

113-003 と、最後のひとけたを入れないと、113-003* に該当する住所がずらっとでてくる。まあ、こういう検索が意味があるのか、私にはよくわかりません。

郵便番号は、999-9999 という3ケタ−4ケタという構造になっているんだから、この構造を素直に表現したほうが良いと思う。

"/住所" だけだと、上の3ケタの一覧がレスポンスされる。

/住所/113 だと、 113 以下の 下4桁の一覧が戻る。

/住所/113/0033 だと、「文京区本郷」にたどり着く。(一つだけ戻ってくる)

まあ、この郵便番号だと、本郷までしか特定できないんだけど、本郷の「丁目」一覧がでてくるほうが、自然だと思う。

郵便局の受け持ち範囲が「本郷」なのは、わかるけど、普通の人は、「郵便局の受け持ち区域」という発想では、暮らしていない。

「郵便番号」関連のサービスを使う時でも、利用者の関心事には「郵便局の受け持ち区域」なんて、持っていない。

ここらへんをもっと気を配ると、サービスのレベルが改良できるんだろうけどなあ。

ちなみに、実際の URI は、

/cgi-zip/zipcode.php?zip=113-003&x=29&y=20

意味不明ですね。 cgi や、 php に関心があるわけないですよねえ。普通は。

google の場合


google も、郵便番号とか、住所で、検索できますね。

http://maps.google.com/maps/geo?&q=1130033
とか
http://maps.google.com/maps/geo?&q=東京都文京区本郷
とか

やると、どんな表現がかえってくるか、興味があるひとは試してみてください。

URI 設計の例としては、query 式なので、あまり興味がわかないけど、レスポンスで戻ってくる内容は、なかなか興味深い。

内容は、一般の人の関心事ではないと思いますが、この API は、どんな人たちのどんなニーズを想定しているかを考えてみるのも面白いかも。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 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