図1 RESTとSOAPの違い<br>図の左側に並んでいる角丸四角形はブラウザなどの情報/サービスの受け手を,右側の四角形はリソースやサービスを表す。RESTでは,リソースとその識別子であるURIが1対1に対応しており,URIを指定するだけで情報を取得できる。
図1 RESTとSOAPの違い<br>図の左側に並んでいる角丸四角形はブラウザなどの情報/サービスの受け手を,右側の四角形はリソースやサービスを表す。RESTでは,リソースとその識別子であるURIが1対1に対応しており,URIを指定するだけで情報を取得できる。
[画像のクリックで拡大表示]

 初回にWeb 2.0の概念が急速に浸透していることをご紹介しましたが,Internet Magazineの素早さには改めて感心しました。2006年4月号の特集「マッシュアップ~Web2.0的サービス構築術」です。

 38~41ページでは,「API公開ウェブサービスカタログ」と称して,マッシュアップの素材として使える公開サービスをカタログ化しています。42~47ページは,「マッシュアップショーケース」ということで,これらのAPIを使った,主立ったWebアプリケーションを紹介しています。海外のサービスには,Elicit(ブログの管理と情報収集の両立)のように,Amazon, Blogger, Bloglines, del.icio.us, Flickr, Google Search, LiveJournal, Technorati, TypePad, Yahoo!Searchと,10本ものAPIを利用したものがあることが分かります。

 もはやマッシュアップは地図だけではないという印象とともに,多数の公開APIが,「もういつでも使えますよ」というメッセージが伝わってきます。前回ご紹介した,企業内外を統合した双方向のマッシュアップのビジョンの実現も予想以上に近いかもしれない,と予感させてくれます。

 ところで,「API公開ウェブサービスカタログ」の表には「プロトコル」という欄があり,公開されたAPIごとに“REST”,“SOAP”あるいはその両方が記載されています。ご存知のように,SOAPはSimple Object Access Protocolの略で,伝統的な(といっても2001年ころからですが)Webサービスを支える基盤規格の一つです。

 ではREST(REpresentational State Transfer)とは何でしょうか?

 Wikipedia になかなか正確な解説がありますが,いかんせんHTTPプロトコルを批判的に理解しようとする技術者以外には敷居が高いものになっています。本来RESTは,アーキテクチャ・スタイルと呼ぶ原則の集まりで,大変抽象的で一般的な概念です。ネットワーク・プロトコルのたぐいを作る際の制約条件の束,ということですが,「貴方もHTTPに対抗した別のネットワーク・プロトコル,作りますか?」と言われて「はい」と答える方はあまりいらっしゃらないでしょう。SOAPとの違いに焦点を当てた別の説明が必要ですね(Wikipediaに補筆しろよ,という声はさておき)。

 図1[拡大表示]は,RESTとSOAPの違いが明確になるように,ブラウザなどの情報/サービスの受け手(図の左側)とリソース(図の右側)の関係を表したものです(山本 陽平氏の講演資料「REST 入門 2005年11月24日 第八回 XML 開発者の日」に掲載された図を基に作成)。すべてのリソースが,一つのグローバルな識別子(URI)によって参照されるといった,RESTの特徴がよく分かります。

 RESTの素晴らしさを語るとき,「URIテキストをブラウザのURL欄に入力したら,すぐWebページにアクセスできるでしょ?」という“デモ”をすることになります。あまりに単純ですが,上記Wikipediaの解説のように奥が深い。まるで禅問答のようでもあります。しかし,REST準拠で設計されたおかげで,すべてが「リソースとその状態」に単純化され,Webシステムのメリット「(開発のカット・オーバーが)早い,安い,(使い勝手などが)旨い」に結びついているのです。

 ではどうするとRESTでなくなるのでしょうか。例えば,誰かが誰か(別のリソース)を隠して,「俺を通さなければ何があるか,どうなっているかを教えてあげない!」と門番のように振る舞ったら,それはRESTでなくなります。図1のRESTとSOAPの比較は,その対比を示しています。

 こうみると,まるでSOAPがWebの美しい世界に侵入して悪さをしているように聞こえるかもしれません。しかし,少なくとも筆者は「それは全く違う」と考えています。

 次回は,このWebの原点に帰ったといえるRESTと,SOAPの対比を通じて,Web 2.0の技術の特徴,ならびに,“伝統的な”Webサービスとの使い分けについて述べたいと思います。