Web API(WebサービスAPI)をプログラミングで活用するにあたって,ぜひ知っておきたい基礎技術が三つあります。古典的な技術の代表としてSOAPとWSDL,そして昨今急速に普及してきたRESTです。ごく単純に言ってしまうと,前者は「高機能で複雑」,後者は「シンプルで簡単に利用可能」と区別できるでしょう。現時点では,そのシンプルさが多くの開発者に受け入れられたおかげか,REST方式が(先達である)SOAP方式を圧倒しているように見えます*1

 もっとも,だからといってRESTがSOAPよりも優れていると結論付けるのは早計でしょう。昨今では,SOA(Service Oriented Architecture)という言葉に代表されるように,大規模なシステムを「サービス」という単位で構成し,互いに連携し合う設計手法が注目されています。特に,SOAを実現する具体的な基盤技術として注目されているのが「Webサービス」です。より大規模なアプリケーションで複雑高度な要件が必要になった場合は,RESTよりSOAPのほうが適しているという局面も発生するはずです。

 そこで本稿では,Web API技術を支えるSOAP,WSDL,RESTが,それぞれどのようなものなのか,じっくり学びましょう。

Webアプリケーションは人が使う
Webサービスはプログラムが使う

 さて,まずは三つの技術の解説に入る前に,そもそもWebサービスというものがどういうものなのかという点から,あらためて考えておきましょう。

 Webサービスを一言で言うと,「ネットワーク上に分散したアプリケーションで共有可能なビジネス・オブジェクト」と定義できます*2。ピンと来ない方は,「Webアプリケーション」と「Webサービス」とを比較して考えてみると,わかりやすいかもしれません。

 いわゆるWebアプリケーション(Webサイト)にアクセスするのは“人間”です。WebブラウザからURLを入力したり,他のページからリンクをたどったり,様々なアクセス方法があるにせよ,エンドユーザーが操作することを前提にWebアプリケーションは作られます。

 これに対して,Webサービスにアクセスするのはコンピュータ(アプリケーション・プログラム)です。例えば,特集4で解説しているAmazon Webサービスを利用するのは,検索処理に必要な情報を問い合わせてその結果をエンドユーザーに表示するアプリケーションです(図1)。プログラマは,Amazonの商品検索機能をあたかも自前のサービスであるかのように利用しているだけです。ここで,Webサービスを利用しているのはあくまで「アプリケーション」であって,エンドユーザーではないことが肝心なのです。

図1●Webアプリケーションを利用するのは「人」,Webサービスを利用するのは「アプリケーション(プログラム)」
図1●Webアプリケーションを利用するのは「人」,Webサービスを利用するのは「アプリケーション(プログラム)」
[画像のクリックで拡大表示]

CORBAやDCOMでは融通が利かない

 もっとも,このようなネットワーク分散型アプリケーションの連携を支える技術は,なにもWebサービスが最初というわけではありません。分散技術に造詣のある方ならば,これまでCORBA*3やDCOM*4のような技術があったことを思い出されるでしょう。実際,ネットワーク上に分散したアプリケーション間でビジネス・オブジェクトを共有するだけなら,今でもこれらの技術を利用することで十分に実現できます。

 しかし,残念ながらCORBAやDCOMは分散アプリケーション連携についての万能技術ではありません。インターネット環境で,しかもアーキテクチャも異なるような不特定多数のシステムを連携させるには無理があります。

 その理由の一つに,CORBAやDCOMがそれぞれ独自のプロトコルを採用しているという点が挙げられます。セキュリティ的な理由から,ほとんどのファイアウォール*5は,通信可能なプロトコルとしてHTTP(HTTPS)しか許可していません。つまり,ファイアウォール越しに独自プロトコルで通信を行おうとしたら,通信を許可するプロトコルをファイアウォールごとに別個に許可する必要が出てきます。これは,技術的には可能ですが,現実的にはとても手間がかかります。サービスや対象ユーザーを特定したケースなら,限定されたプロトコルのみを許可するという選択肢も(あるいは)ありうるかもしれません。しかし,不特定のサービス/ユーザーそれぞれに異なるプロトコルを許可するという選択肢は,現実的ではありません。

 二つ目の理由は,インターネット技術の普及で,異なるアーキテクチャのアプリケーションの相互運用が当たり前のものになってきたという事実です。なるほど,DCOMやCORBAによるオブジェクト呼び出しの手続きは,それぞれのアーキテクチャに閉じている限り最適化できます。しかし,CORBAからDCOMへ,あるいはDCOMへCORBAへと通信を行おうとした場合にはどうでしょう。確かに相互連携するためのブリッジを利用するような方法はありますが,特定のミドルウエアに限定されたり,実現できる機能自体がブリッジに依存したりするなど,アーキテクチャ間の溝を根本的に埋めるものではありません。

 このような問題を解決するのが,Webサービスなのです。WebサービスがCORBAやDCOMと根本的に異なるポイントは,以下の2点です。

・情報の送受信を標準的なHTTPプロトコル上で行える*6
・XML(Extensible Markup Language)ベースで情報を授受するので,特定のプラットフォームに依存しない

つまり,WebサービスがCORBAやDCOMのような既存技術と決定的に異なるのは,「特定の言語やプラットフォーム,プロトコルに依存しない」ということになります。

SOAP――Webサービスを
利用するためのメッセージ・ルール

 ところで,Webサービスと一口に言っても,Webサービスという名前の単一の技術が存在するわけではありません。Webサービスとは,メッセージ技術,インタフェース記述技術,セキュリティ技術など様々な技術から構成される複合技術です。それらの技術の中で,まず真っ先に重要なものとして挙げられるのがSOAPでしょう。

 SOAPは,Simple Object Access Protocol*7というその名の通り,ネットワーク上のオブジェクトにアクセスするためのシンプルな通信プロトコルのことです。

 冒頭で説明したように,Webサービスにも,サービスの提供者としての「サーバー」があり,サービスの利用者として「クライアント」があるのは,一般的なWebアプリケーションと変わりません。Webサービスを利用するために,クライアントはサーバーに対してリクエスト情報(どのサービスを利用したいか,サービスの実行に必要なパラメータなどの情報)を送信し,サーバーからはクライアントに結果を応答する必要があります。これらやりとりのルールを定義するのがSOAPなのです。

 もっとも,これだけのことなら「SOAPなど必要ない,HTTPプロトコルで十分じゃないか」と思われるかもしれません。確かにHTTPはWeb標準のプロトコルで,クライアント/サーバー(C/S)間の要求/応答を管理できます。コンテンツの処理は原則としてWebブラウザに委ねられ,XML文書,PDF文書,画像,音声,動画など,送信するコンテンツの種類は自由です。HTTPプロトコルで必要な情報をやりとりしても何ら問題はないように見えます。では,どうしてSOAPなどという新しい仕組みが必要だったのでしょうか。