REST 入門(その10) 終わりに

» Permanent link | |

» REST 入門 目次

前回まで、REST 入門ということで、 REST アーキテクチャスタイルとは何なのか、 について基礎的なところを結構細かく :-) 説明してきました。 REST 入門はこれで終わりですが、最後にロイ・フィールディングの論文から REST アーキテクチャスタイルの各制約を抜き出して説明します。

Null スタイル

最初は、制約がまったくないところからはじまります。それが Null スタイルです。

クライアント・サーバ

最初の制約はクライアント・サーバです。REST がクライアント・サーバから派生していることは、 "2. アーキテクチャスタイルとは" で解説しました。

ステートレス

REST スタイルにおいて、サーバはクライアントの状態を管理しません。すべての状態はクライアントで持ちます。 クッキーでの状態管理が REST でないことは "8. REST でないもの" で説明しました。

キャッシュ

REST スタイルではサーバが返す結果をクライアントでキャッシュ可能なように設計します。 これによりネットワーク効率を向上させることができます。

統一インターフェース

REST の制約で最も特徴的なのがこの統一インターフェースです。 クライアントはどんなシステムとでも同じインターフェースで接続できます。 統一インターフェースについては "4. HTTP GET -- その絶大な効果"と "5. 四つの動詞 -- GET, POST, PUT, DELETE"で説明しました。

階層化システム

このシリーズでは説明しませんでしたが、REST スタイルの制約にシステムを階層化できることがあります。 これにより、たとえばロードバランサーでの負荷分散や、レガシーシステムのラッピング、proxy サーバなどが可能になります。

コードオンデマンド

この制約も説明していません。 REST では、クライアントがコードをサーバからダウンロードして実行することができます。 たとえば Javascript ですね。ただし、この制約はオプションです。

終わりに

僕がこの REST 入門シリーズを書いた目的は二つあります。 ひとつは「目次」で書いたとおり、日本語での REST の基礎的な資料を作るためです。 日本では Amazon Web サービスの REST API のような単純な XML over HTTP としてしか REST が認識されておらず、 往々にして間違った議論がされていたり、あるいはアーキテクチャスタイルとしての REST が注目されていなかったりします。 しかし REST は Web における次の5年の(もっとか?)基盤技術であると、僕は思っています。 各個人がどう評価するかはともかく、REST を知らずに Web を語ったり議論したりするのは非常に危ういと思うのですね。 そういう意味で、REST 周辺の言葉を整理して (Architectural Style の日本語訳も悩んだのです)、 日本でもちゃんと話ができるようにしたかった。 結果としては naoya さんに紹介してもらって僕の weblog のページビューも10倍くらいになりましたし、 WWW2005 後くらいから REST で検索してくる人が非常に多くなったので、 このシリーズをやってよかったなと思ってます。

もうひとつ、僕が言いたかったことは、せめて技術者が技術に接するときは純粋にそれを技術として評価しよう、ということです。 SOAP や WS-* の世界は、ベンダの対立など半ばゴシップ的な記事が IT 系ニュースサイトの紙面を躍らせるので、 どうしても脊髄反射的に「だから WS-XX は駄目なんだ」とか言いたくなるのですが、それは変なんですよね。 WS-* は確かに重くてすべてを理解するのは大変なんですけど、 Microsoft や IBM が無意味にあんなにリソースを割いて推進するわけがないのです(ハロウィン文書の例の戦略だ、というハナシもありますが)。

たとえば WWW2005 のパネルで SOAP/WS-* を厳しく批判していた Tim Bray や Adam Bosworth は SOAP/WS-* のことを何も知らずに批判しているわけではないのです。 むしろ、知っているからこそ批判できるんです。 SOAP/WS-* 側の人間にしても同じです。 Don Box や Jeffrey Schlimmer, Dare Obasanjo, Tim Ewald, Dave Orchard みんな REST のことはきちんと知っている。 だいたい Dave Orchard と Tim Bray なんてランチしてたりするし、 その他の人々も W3C のメーリングリストやミーティングなんかでちゃんと交流して議論しているわけです。 そういえば Tim Bray だって昨年の XML Developers' Conference (Microsoft よりのカンファレンス)で講演してました。

とまあ、僕も偉そうなこと書いてる割に REST をきちんと評価したのは昨年の8月くらいだったりします。 それまでは Web サービス = SOAP/WSDL で RPC だったんですが、 document/literal になってからイマイチわからなくなってしまった。 で、いろいろ調べたり考えたりしてやっと REST にたどり着きました。 「REST は XML の王道」とかキャッチーなことも書いてますが、 REST 万歳、SOSP/WS-* ダメダメと言うつもりはなくて、 両方ちゃんと評価しよう、ということです。

この weblog の今後ですけど、シリーズものだと普段はあまり気が乗らない基本的なことも書く気がおきてよい感じなので、 もう一回やってみようかと思ってます。 題材は今話題の(?) Web 2.0 にするつもり。 ではまた。

REST 入門(補足) アーキテクチャとアーキテクチャスタイル

» Permanent link | |

» REST 入門 目次

僕の説明だと、どうもアーキテクチャとアーキテクチャスタイルについて混乱を招きそうなので、 補足しておきます。 デザインとデザインパターンが違うように、 アーキテクチャとアーキテクチャスタイルは別物です。 デザインパターンの本といえば GoF とか結城さんの2冊が有名ですね。 デザパタ本に載っているのはデザインそのものではなくデザインのパターンです(ムズカシイ?)。

つまりこういうことです。 僕たちは結城さんの本でデザインパターンを勉強します。 デザインパターンはある問題領域においての経験則的なクラス設計の指針、作法、流儀です。 あの本自体に自分のプログラムのデザイン(設計)が書いてあるわけではありません。 本に書いてあるパターンを学習して、そのパターンを自分自身のプログラムのデザインに適用します。 デザインというのは本に書いてあるのではなく、 僕たちが実際に作るプログラムにおいて初めて具現化されるものなのです。

アーキテクチャスタイルも同様です。 現実の世界で作られる実際のシステムはアーキテクチャを持っています。 そのアーキテクチャを設計するときに、ただ闇雲にものを作っていくのではなく、 世の中にすでにたくさんあるアーキテクチャ設計の指針、作法、流儀を適用するはずです。 そのほうが作業効率がいいし、先人の知恵を活用することできちんと動くものが作れるから。

でも、実際は忙しかったり、納期が迫っていたり、 調べるのが面倒だったり、とにかく作らなければならなかったり、 あるいは単に無知だったりして、アーキテクチャスタイルを適用しない(できない)こともあります。 すると、いちおう動くんだけどちょっと変なシステムや、 最悪だとパフォーマンスやセキュリティに重大な欠陥を抱えたシステムができたりします。

REST の実装は Web だといいましたが、 REST じゃない実装の Web もあります。 後ほど詳しく説明する予定ですが、 たとえば Cookie、たとえば URI へのアクション埋め込み、 キャッシュを無視した POST の濫用、 などはすべてアーキテクチャスタイルとしての REST を無視したか、 あるいは知らないために起きている問題です。

本題がちとずれました。 元の話(アーキテクチャとアーキテクチャスタイル)に戻ります。 アーキテクチャはあなた自身のシステムのものです。 それを作るときに、アーキテクチャスタイルを適用しましょう。

REST 入門(その2) アーキテクチャスタイルとは?

» Permanent link | |

» REST 入門 目次

REST そのものを説明する前に、まずアーキテクチャスタイルとは何なのかを解説します。

アーキテクチャスタイル(英文では architectural style です) は別名(マクロ)アーキテクチャパターンともいい、 複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉です。 パターンという言葉からデザインパターンを想像する人も多いかもしれませんが、 いわゆるデザインパターンは別名マイクロアーキテクチャパターンといい、 アーキテクチャスタイルよりも粒度の細かいクラスなどの設計様式を指します。

具体例を挙げましょう。
たとえば MVC (Model View Controler) はアーキテクチャスタイルの一種です。 他にパイプ&フィルタ、インタプリタ、イベントシステムなどもアーキテクチャスタイルになります。

REST は数あるアーキテクチャスタイルの中でも特にネットワークシステムのアーキテクチャスタイルになります。 ネットワークシステムのアーキテクチャスタイルとして最も有名なのはみなさんご存知のクライアントサーバです。 サーバとクライアントが線で結び付いている絵を思い浮べてください。

クライアントサーバと聞いて「あれれ」と思った人がいるかもしれませんね。 「はじめに」で REST は Web のアーキテクチャスタイルだと言いました。 しかし、Web はクライアントサーバでもあります。 これはいったいどういうことでしょうか。

実は REST はクライアントサーバから派生したアーキテクチャスタイルなのです。 素のクライアントサーバアーキテクチャスタイルにいくつかの制約を加えていくと、 REST アーキテクチャスタイルになります。 この「制約」というのはアーキテクチャスタイルにおいて重要な概念です。 一般にソフトウェアアーキテクチャは複数のコンポーネントを組み合わせて実現しますが、 それぞれのコンポーネントがバラバラに動いているのでは動作しません。 そこで、各コンポーネントに制約を課していきます。 その結果、全体として各コンポーネントが協調して動作するようになります。

クライアントサーバから REST に至る過程で加えられた制約には、 たとばステートレスやキャッシュなどがあります。

最後に、アーキテクチャスタイルとは特定の実装を指すものではないことに注意してください。 WWW は REST の一実装形態です。WWW 以外の REST の実装も考えられます。 しかし、現実には REST といえば WWW のアーキテクチャスタイルを指す場合が多いので、 これからは特にことわりなく REST の実装例として WWW を使っていきます。

次はやっと REST そのものについて記述します(長いなー)。

[update 2005-04-27 アーキテクチャとアーキテクチャスタイルについて補足を追加しました。]

Service Oriented の正体

» Permanent link | |

Newcastle upon Tyne 大学の Savas Parastatidis のこのポストが面白い。いや面白いというか感動した。ここ最近 Web サービス、REST などに関して混乱している僕に一筋の光明を照らしてくれたような気がする。Savas いわく分散システムの実現手法には以下の三つがある。

1. オブジェクト指向
2. リソース指向
3. サービス指向

彼はこれらの手法を、それらが採用する building block で特徴付けている。

オブジェクト指向の building block はインターフェースとオブジェクトだ。コミュニケーション抽象化はメソッド呼び出しの粒度で行われる。たとえば以下のような例が挙げられている

interface Calendar {
    Appointment CreateAppointement(Person, DateTime);
    void Cancel(Appointment);
}

リソース指向(REST)の building block はリソースと統一されたインターフェースである。オブジェクトとリソースの最大の違いはリソースそれ自身がメソッドを持たないところにある。リソース指向ではリソースの操作は統一されたインターフェースだけを介して行われ、それ以外の方法では操作されない。この統一されたインターフェースを、セマンティクスによって呼び分けるのも大きな特徴である。すなわち、オブジェクトは呼び出し可能な実体であるが、リソースはそうではないということだ。上記の例はリソース指向(REST)で書きなおすと以下のようになる。

POST InformationAboutNewAppointment 
TO http://calendar.com/appointments AND 
SEND created, http://calendar.com/appointments/123

これらに対してサービス指向ではどうか。サービス指向のにおける biulding block はサービスとメッセージである。ここで Savas が持ち出す記法はすごい。まずは以下の例を見てほしい。

AppointmentRequestMsg TO CalendarService FROM sender
AppointmentInformationMsg TO sender FROM CalendarService

AppointmentCancellationMsg TO CalendarService FROM sender

この記法の意味するところは次のようなものだ。まず AppointmentRequest メッセージが送信者から Calendar サービスに送られる。次に Calendar サービスから送信者に AppointmentInformation メッセージが送られる。見方によってはこれはリクエスト・レスポンスになるが、メッセージが送信・処理される、という一方向の組み合わせに過ぎない。それは Cancel の方を見るとよくわかる。 Cancel ではメッセージは送信者からサービスに送られるのみである。サービスから送信者には何もメッセージが送られない。オブジェクト指向や REST では一方向を実装規約で乗り切っていたことを思い出してほしい。オブジェクト指向では void という戻り値で、REST では空のメッセージを返すことで、一方向メッセージを実現していた。しかし、サービス指向では全ては一方向メッセージ交換、とその組み合わせで実現される。

Savas はこれを ProcessMessage Architectural Style と呼んでいる。そう、これは一つの Architectural Style なのだ。このスタイルではオペレーションはこの「メッセージを処理する」という意味の ProcessMessage しか存在しない。

このほかにもこのポストでは興味深い考察がいくつも挙げられている。WS-Transfer の位置づけや、サービス指向における verb の扱いについて、さらに WS-Addressing における wsa:Action の存在についてだ。

最後に彼は WSDL を IDL として使うことや、CORBA のオブジェクトをそのまま Web サービスとして出すことに反対している。これに通じる流れとして WSDL 2.0 に明確に反対する記事も出てきている。こちらも見逃せない。