yohei-y:weblog

XML と REST/Web サービス関連の話題が中心の weblog です

2007-04-19

WEB+DB PRESS Vol. 38

WEB+DB PRESS Vol. 38 で REST 周りのことについての連載を始めました。

ちょうど1年前に REST の解説を書いたんですが、 その直後に naoya さんが連載で、と書いてくれて それを見た技評の中の人が mixi で「連載しませんか」というメッセージくれたんだけど、 ちょっと1年続くネタに困りそうなのでやんわりと断ったのでした。 んで、1年後、技評の中の人がもう一度話を持ってきてくれて、 今年は APP もついに RFC になりそうだし、 連載してもいいかなーと思って連載することにしました。 ということで何が言いたいかというと、naoya さんの影響力と 技評の中の人の企画力はすごい、ということでした。

肝心の今回の内容ですが、円グラフで表現すると、こんなかんじです。

べつやくメソッド

photo
WEB+DB PRESS Vol.38
WEB+DB PRESS編集部
技術評論社 2007-04-24

ラベル: , ,

2005-08-12

良い URI の設計

URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakesこのエントリです。 Tanya Rabournリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは

  • 変らない(don't change)
  • 人間が推測可能(are human guessable)
  • 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem))
  • サイト構造をビジュアライズするのに役立つ(help visualize the site structure)
  • 短い(are short)
  • 小文字を使う(use lowercase)
  • 予期されない記号を使わない(don't use unexpected punctuation)
  • 問合せパラメータなし(lack query parameters)
  • 公開リンクを許す(allow public linking)
  • ステートレス(are stateless)
  • 技術を丸出しにしない(dont expose technology)

だそうです。 彼のエントリにはそのほかにも Flickr の URI が良い設計例として載っています。

典型的な悪い例はこんな感じかな。

http://test1.example.com/Test/getDocList.cgi?folder-name=abc&user_name=yohei&sessionId=123

直すとこうなる。

http://www.example.com/yohei/abc

最後の項目の悪い例は /home.pl とか /login.do とか /index.jsp とか /hitobito.nsf とかですかね。 とりあえずは mod_rewrite を使って解決するんでしょうけど、本質的にはフレームワークが解決した方がよさげ。

ラベル: ,

2005-07-31

Web らしく URI で連携する方向

前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。

僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。

これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。

ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。

<link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
<link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />

body 内部で a タグに書くのであればこんな感じ。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei" >はてぶ</a>
<a rel="hatenaa" href="http://a.hatena.ne.jp/yohei" >はてあ</a>

ここまでくると、別にはてなに限らないでもいいのではないかという気がしてきます。 たとえば僕の場合、使っていると宣言したいサービスは

  • hatenab
  • hatenaa
  • flickr
  • bloglines
  • delicious
  • mixi
  • blogger

なので、head はこうなります。

<head>
  <link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
  <link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />
  <link rel="bloglines" href="http://www.bloglines.com/public/yamamotoyohei" />
  <link rel="flickr" href="http://www.flickr.com/photos/60043209@N00/" />
  <link rel="delicious" href="http://del.icio.us/yohei" />
  <link rel="mixi" href="http://mixi.jp/show_friend.pl?id=173690" />
  <link rel="blogger" href="http://yohei-y.blogspot.com" />
</head>

a タグだったらこうなります。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei">僕のブックマーク</a>です。
<a rel="mixi" href="http://mixi.jp/view_profile.pl?">mixi</a>も使ってるよ。
<a rel="payment hatenagesen" href="http://nagesen.hatena.ne.jp/yohei">投げ銭</a>よろしく。

この rel= はいわゆる microformats ですね。 link タグなら Atom feed にも同じように入れられます。

rel 属性の値が各サービスごとに違うのがいいのか、 もっと別の値がいいのか、そもそもこんなことがやりたいのか、やっていいのか、という話はありますが (^^; URI で繋がるという方向性もある、ということを認知してもらえたらと思います。

ラベル: , , ,

2005-04-23

REST 入門(その3) 全てはリソースから

» REST 入門 目次

では(やっと) REST の具体例を見ていきましょう。

REST で最も重要な概念はリソースです。以下にリソースの具体例を挙げてみます。

  • 東京の天気予報
  • 2005年8月24日のスケジュール
  • 新花巻駅の写真
  • Dijkstra 著 "Go To Statement Considered Harmful"
  • 僕の最近のブックマーク

REST においてリソースとは名前のつくあらゆる情報を指します(つまり名詞ですね)。 たとえば、「東京の天気予報」というリソースには今日の天気予報も明日の天気予報も含まれるでしょう。 あるいは「2005年8月24日のスケジュール」には僕のスケジュールだけでなく、 あなたのスケジュールも含まれるかもしれません。 リソースで重要なのは、その意味です。 リソースの実体は時間や条件によって変化するかもしれませんが、 その意味は不変です(これが名詞たる所以)。

上記のリソースの例を再度見てください。 これらは WWW (= REST の実装) 上に存在するものばかりです。

  • 「東京の天気予報」は Yahoo Japan の東京地方の天気予報のページ
  • 「2005年8月24日のスケジュール」は会社のグループウェアのスケジュール
  • 「新花巻駅の写真」は Flickr に登録した東北旅行のときの一枚の写真
  • 「Dijkstra 著 "Go To Statement Considered Harmful"」はこのページ
  • 「僕の最近のブックマーク」はソーシャルブックマークサイト del.icio.us のページ

といったぐあいです。

全てのリソースは識別子を持ちます。 Web の識別子といえば、URI (Uniform Resource Identifier) ですね。 もう一度サンプルを見てください。

それぞれの URI は以下のようになります。

  • http://weather.yahoo.co.jp/weather/jp/13/4410.html
  • https://example.com/schedule/20050824
  • http://www.flickr.com/photos/60043209@N00/6337155/
  • http://www.acm.org/classics/oct95/
  • http://del.icio.us/yohei

ここで、リソースの特徴を考察してみます。 上記の例のとおり、リソースは URI で識別される情報です。 URI で識別される情報は、時間や条件によって内容が変化する可能性があります。 たとえば、今日見る天気予報と明日見る天気予報では、含まれる内容は異ります。 しかし、両者とも東京の天気予報であることにはかわりありません。 今、リソースの内容と書きましたが、その内容は取得する時点でのリソースの状態(state)で決まります。 天気予報というリソースは、時間の経過と共に状態が変化していくと考えるとわかりやすいと思います。 もちろん状態が変化しないリソースもあります。 ダイクストラのレターの状態が変化する可能性はもうないですよね。

ここまでで、REST におけるリソースの特徴をまとめると以下のようになります。

  • 全ての情報はリソース
  • リソースは識別子(URI)を持つ
  • リソースの状態は時間や条件とともに変化する可能性がある
  • リソースの意味は時間や条件が変化しても不変である

このリソースが、REST では非常に重要になります。 その秘密は、次回以降で説明します。

ラベル: ,