ricollab Web Tech Blog » rest

RESTful Web サービス読書会

yohei — Wed, 28 May 2008 00:59:04 +0000

少し前の話ですが、RESTful Web サービス読書会に参加してきた山本です。

この会は kunitさんが企画・運営されている読書会で、毎月第二土曜日の午後をほぼフルに使って、田町のキャンパスイノベーションセンターで開催されています。

私は初回に監訳者としてリアルで参加し、第2回はリモートで ustream の中継を見ながら lingr 等のチャットで観戦・参戦しました。

こういった読書会に参加するのは初めてだったのですが、普段なかなかお会いできない異業種の方(今回の場合はPHP)と、直接話すことができて大変有意義な会でした。土曜日の午後、田町に出かけられる人にはぜひお勧めの勉強会です。

また、リモートでもかなりきちんと試聴できるので、関東近県以外にお住まいの方も参加可能です。さすがにリモートでの発表はちょっと難しそうですが、チャットでの議論もかなり役に立つと感じています。

こういうことを書くと年寄りくさくなりますが、自分が若いころはこのように色々な人と出会える勉強会はなかなかありませんでした。自分の経験で言うと、隣の研究室と輪講したり、学会や研究会に出た程度でした。

それが今ではその道のプロとすぐに情報交換できてしまうのですから、まさに高速道路が用意されているという気がします。

若い人たちにはぜひ、こういう機会(別に勉強会じゃなくてもいいですけど)を有効活用してもらえればと、なんだかオッサンのようなまとめになっちゃいました。

WEB+DB PRESS Vol. 44

yohei — Wed, 30 Apr 2008 04:54:01 +0000

こんにちは。山本です。

先週発売になった WEB+DB PRESS Vol.44 で、先日公開した郵便番号検索サービスの設計の解説を書きました。

郵便番号の検索はかなりシンプルな機能ですが、仕様書として書き下すとそれなりの分量になります。この仕様書は私がスクラッチから作成したのですが、今回の記事ではこの仕様書を書くにあたって行った設計作業をそのまま文章として書き出してみました。

リソース設計の基本は RESTful Web サービスで紹介されているリソース指向アーキテクチャ(ROA)の設計手順に従っています。この手法の良いところは、フレームワークに依存せずにリソースを考えられるところです。

最初にリソースとその URI を設計し、URI Templates を使って機械的に各リソースとそれに対する操作をコントローラやモデルに振り分けていくという流れがRESTful な Web システムの設計の王道になっていくのではないかと思っています。

その点で、規約によって URI が固定されてしまう Rails 2.0 は不利なんじゃないかと考えています。ROA を主眼に置いた Web システムの設計はまだまだやることがありそうですね。

RESTアーキテクチャスタイル入門の記事をすべて公開しました

yohei — Fri, 04 Apr 2008 04:21:10 +0000

1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。

RESTアーキテクチャスタイル入門

出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。

RESTとROAの社内技術交流会資料と映像を公開します

yohei — Mon, 24 Mar 2008 03:58:25 +0000

こんにちは。山本です。

先月 NTT コミュニケーションズ様で講演した内容を報告しましたがその後なんで社内でやらないのだとツッコミをうけたので、社内の技術交流会でほぼ同じ内容で発表しました。

せっかくなので、このブログでも報告できるようにと映像を撮ってあります。リコーの MPMeister という動画とパワーポイントスライドを同期させたWebコンテンツを簡単に(本当に簡単です)作成できるツールを使って作成しました。MPMeister は残念ながら Windows/IE 限定のツールなのでそれ以外のブラウザの方用に Flash のコンテンツも用意しました。

2/27 ソフトウェア研究開発本部技術交流会「RESTとROA」(MPMeister版) (Windows/IE 限定です。Firefox の方は開かないでください。ブラクラですorz)

当日使った資料も PDF で置いておきます。

プレゼン当日に社内の一部で妙にニコニコメソッドが話題になっていたため、実施してみました。講演者はスライドばかり見ているわけではないので、何が起っているのかわからないことも多いのですが、参加者の皆さんには大変好評でした。途中でソフトが落ちてしまったので、一次中断していますが、後半また復活しています。

ちなみにこれに影響を受けた日野原は、Air 版をいろいろいじって遊んでいるようです。

RESTとリソース指向アーキテクチャについての資料

yohei — Wed, 13 Feb 2008 05:48:24 +0000

2/12 に NTT コミュニケーションズ様の社内勉強会にて、REST に関する講演をさせていただきました。NTTコミュニケーションズ様の了解をいただいたので、その資料を公開します。

REST を具現化するアーキテクチャとして、「RESTful Web サービス」で提案されているリソース指向アーキテクチャ(Resource Oriented Architecture; ROA) をご紹介しました。

リソースの考え方

yohei — Thu, 10 Jan 2008 02:14:15 +0000

Web アプリケーションや Web サービスを RESTful に設計するときに、まず大切になるのはリソース設計(リソースモデリング)だと考えています。私が自分でサービスを開発するときは、そのサービスでどんなリソースを提供するのか、をまず考えるようにしています。

リソースの設計は、関係データベースのスキーマ設計のように系統立ててまとまった手法は存在しません(情報アーキテクチャは一つのスタートポイントになるのでは、と考えています)。

今回は以前、社内向けにまとめたリソース設計に関する文書を再構成してみました。何かのヒントになれば幸いです。

＃余談ですが、RESTful Web Services を初めて読んだとき、表現の選択のところで出てくるフォーマットリストとほとんど同じものが9章に出てきてちょっとびっくりした思い出があります。

概要
リソースの考え方
リソースと URI
リソースとリソースの表現
リソース表現の選択肢
Web API とリソース
まとめ

概要

Web サービスや Web アプリケーションの設計を行うときは、どのようにリソースを分割していくかが重要となります。本文書では、REST (Representational State Transfer) におけるリソースについて簡単に振り返り、新しくリソースを作成する際のヒントを示します。

リソースの考え方

REST の定義に従えば、リソースは情報の断片です。

しかし、それではあまりに抽象的すぎるので、ここではもう少し具体的な定義をします。

リソースはたとえば以下のようなものです。

東京の天気予報
新花巻駅の写真
Dijkstra 著 “Go To Statement Considered Harmful“
私の最近のブックマーク

これはすべて Web 上にあるデータです。そう、リソースとは Web 上にあるデータを少し抽象化したものだと考えても構いません。

概念的には Web 上にないデータでもリソースと捉えることは可能ですが、無理にはやらない方がよいでしょう。たとえば「人」というリソースを考えるのは面白いですが、残念ながら物理的な人は Web 上でデータとして存在し、やりとりされることはありません。

Web 上に存在するのは「人」ではなくて「人のブログ」だとか「人の写真」でしかないのです。

リソースと URI

Web 上のリソースの大きな特徴の一つとして、「全てのリソースが URI を持つ」ということが挙げられます。リソースが URI を持つことでリソース同士をリンクさせることができるのです。

リンクは Web を考える上で非常に重要です。リンクされていない Web ページは Web 上に存在しないも同然だからです。

リソースとリソースの表現

リソースは情報、あるいは Web 上のデータだと述べました。このリソースをサーバ・クライアント間で転送するときのデータ形式のことをリソースの表現といいます。

一つのリソースでも複数の表現を持つことがあります。

たとえば2006年10月10日の東京地方の天気予報、というリソースを考えてみましょう。このリソースの URI はたとえば以下のようになります。

  http://weather.example.com/20061010/tokyo

HTTP クライアントがこのリソースを GET するとこのようになります。

リクエスト

GET /20061010/tokyo HTTP/1.1
Host: weather.example.com

レスポンス

HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 2006年10月10日の東京の天気

2006年10月10日の東京の天気

晴れ

ここでサーバからクライアントに返されているのは、 2006年10月10日の東京地方の天気予報、というリソースの「HTMLによる表現」です。

このリソースは「晴れ」という情報を持っていますが、その表現形式は HTML であっても、 XML であっても PDF であっても画像であっても音声あっても映像であっても構いません。重要なのはこのリソースが「2006年10月10日の東京地方の天気予報」を表しているということです。

HTTP の Accept リクエストヘッダを使うと、欲しい表現の形式の優先度を明示的に指定することもできます。以下の例は Atom 形式の表現を HTML 形式の表現よりも高い優先度でリクエストしている例です。

リクエスト

GET /20061010/tokyo HTTP/1.1
Host: weather.example.com
Accept: application/atom+xml;q=0.9,text/html;q=0.5

レスポンス

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8


  2006年10月10日の東京の天気
  2006-10-10T00:00:00Z
  foo bar
  
    晴れ

リソースと URI は1対1の関係ではないため、複数の URI が同一のリソースを指すこともできます。たとえば、上記の天気予報の URI

http://weather.example.com/20061010/tokyo

と、HTML 表現や Atom/PDF 表現を明示的に参照する URI

http://weather.example.com/20061010/tokyo.html
http://weather.example.com/20061010/tokyo.atom
http://weather.example.com/20061010/tokyo.pdf

は同じ「2006年10月10日の東京地方の天気予報」というリソースを指しています。

リソース表現と選択肢

上述のように、一つのリソースを提供するのにも、いくつもの表現の選択肢が考えられます。ここでは、代表的な表現の形式とその特徴を簡単に説明します。

HTML/XHTML
- Web 上で最も一般的な形式
- ブラウザで表示できるので、人間が読める
- ここで挙げた形式の中で最も自由度が高い
- 逆にいうと最もあいまいな形式
microformats(XHTML)
- イベント情報、レビュー、コンタクト情報といったあらかじめ決められたデータ形式を XHTML に埋め込むための規格
- XHTML の class, rel 属性を利用するだけなので、他の形式との親和性が高い
- XHTML のあいまいな部分をある程度制限し、人間が読むだけではなくプログラムからも扱いやすい形式
- XHTML と併用可能
- microformats.org で定義されていないものは一般性に欠ける
Atom feed/entry (RFC 4287)
- HTML が人間用ならば、Atom はプログラム用の代表形式
- XML なので HTML よりもあいまいな部分が少い
- contents 要素などに XHTML を入れることができる
- タグの拡張が自由
- ある程度のメタデータ(ID、タイトル、日付、著者)はあらかじめ決められている
- AtomPub との親和性が高い
画像(gif/jpeg/png/pdf)
- これらの形式でしか表現できないリソースも多い
- HTML の img 要素からリンク可能
JSON/JSONP
- Javascript から利用しやすい呼出しやすい
  - Javascript 以外のプログラミング言語のバインディングもある
- データ表現に優れている
  - 配列、データ型、ハッシュなどの表現も可能
- XML(XHTML/Atom) よりも記述がコンパクト
- HTML の script 要素からリンク可能

Web API とリソース

ここまでずっと Web API という言葉を出さずにリソースについて説明してきました。

いわゆる Web API というのは、 URI と HTTP を使ってリソースを提供し、編集・更新する仕組みです。すべてのリソースは URI で特定でき、HTTP を使ってさまざまな表現形式でクライアントとサーバの間のやり取りが行われます。

HTTP ではメソッド情報は固定されています。オブジェクト指向設計でクラスの振る舞いを考えるように、リソースの振る舞いを考えても HTTP メソッドは追加できません。リソースに新しいメソッドを追加したくなったら、別のリソースを用意するのが正しい考え方です。このように、HTTP を使った Web API の設計では HTTP メソッドを限定したり、拡張したりすることはなるべく避けるべきです。

この HTTP メソッドを固定する考え方を統一インターフェースと呼びます。すべてのコンポーネント間で、ただ一つのインターフェースを使うことで、世界規模での相互運用性が初めて確保されるのです。

Web API は、URI と HTTP を使ってリソースを操作する仕組み、と言い換えることもできます。

まとめ

Web API を設計する上で、最も重要なのはリソースの設計です。リソースの設計は大きく次の二つに分けられます。

リソースの URI の設計
リソース表現の設計

リソースは抽象的な概念ですが、今我々がブラウザから使っている Web をあてはめて考えると非常にわかりやすくなると思います。ブラウザを人が操作しているところが、プログラムにかわるということです。

リソース設計で悩んだときは、そのリソースの HTML 表現を考えてみましょう。

WEB+DB PRESS Vol.32 に掲載された REST 入門の記事を公開します

yohei — Tue, 08 Jan 2008 01:50:43 +0000

2006年5月発行の WEB+DB PRESS Vol.32 に寄稿した「REST入門」を、技術評論社さんの許可を得て公開します(技評さんは太っ腹ですね)。全体は長いのでまずは1/3を。後半も順次公開予定ですのでお楽しみに！