第8章 マッシュアップ
WebサービスとマッシュアップAPI

マッシュアップとマッシュアップAPI

Webアプリケーションにおける「マッシュアップ」は、他者がWebサーバを通じて提供するソフトウェア機能を積極的に再利用することによって、自らのWebアプリケーションを少ない手間で構築することをいう。

マッシュアップの模式図を次に示す。

図8-1： クライアント側マッシュアップ(左)とサーバ側マッシュアップ(右)

マッシュアップAPI

素材サーバにゲストリソースを要求するインタフェースを「マッシュアップAPI」と呼ぶ。マッシュアップAPIが提供される形態には、主に次の3種類がある。

• Webサービス
• JavaScriptモジュール
• ユーザインタフェース部品（ウィジェット）

集約地点とマッシュアップAPI呼び出し

素材サーバからゲストリソースが集められる「集約地点」には、マッシュアップAPI呼び出しが並ぶ。集約地点がブラウザ上にあるものがクライアント側マッシュアップ、主催者サーバ上にあるものがサーバ側マッシュアップである。これらのふたつの間では、呼び出しに利用できるAPIの形態がいくいぶん異なる。

Webサービスの形態をとるマッシュアップAPIは、HTTPリクエストを用いて呼び出すAPIであり、クライアント側マッシュアップとサーバ側マッシュアップの両方から呼び出すことができる。

JavaScriptモジュールやユーザインタフェース部品の形態をとるマッシュアップAPIは、ブラウザにコンテンツの断片をロードするものであり、たいていは、クライアント側マッシュアップからのみ呼び出すことができる。これらをサーバ側マッシュアップで利用することは、多くの場合、難しい。

マッシュアップAPI呼び出しの際の考慮事項

マッシュアップAPIを呼び出す際、次のふたつを考慮する必要がある。

• 他者が運営する素材サーバは必ずしも信頼できるとは限らない
• 素材サーバへのリクエストは常に成功するとは限らない

前者への対策には、APIへ与えるパラメータを必要最小限のものにとどめ、送られてきたリソースも所定の仕様に従っていることを十分検証してから使用するということが挙げられる。

後者への対策には、呼び出し失敗時に適度なリトライを行うが、素材サーバがそもそもダウンしている際は早めに見切りをつけるよう、バランスをとりつつロジックを設けることが挙げられる。

Webサービス

Webサービスは、マッシュアップAPIの中で最も基本的な形態のものである。動的なWebコンテンツの形で用意されていて、アプリケーションプログラムからのHTTPリクエストに応答する。ここで返されるレスポンスの内容は、HTMLドキュメントではない。多くの場合、XMLやJSONの形式の文字列データである。

最近のWebサービスの傾向

今日の Webサービスには下記の特徴をもつものが増えている。

POST /jp/tokyo/bunkyo-ku/honkomagome/2/28 HTTP/1.1

のように、URI　のパス階層を使って到達経路が示される。

RESTスタイルの URIパスと従来のパスの違い

かつての Webサイトは、Webサーバ内のあるディレクトリ階層以下のファイルをWebサーバソフトウェア（httpデーモン）やアプリケーションプログラムを通じてブラウザへ開示する仕組みのものが多かった。

サーバ内のファイルシステムをそのまま利用することが多かったため、ブラウザから次のようなディレクトリトラバーサル攻撃パターンが送られてくるとサーバ内の秘密ファイルを漏洩してしまうという脆弱性が発生しがちであった。

GET /../../../../etc/passwd HTTP/1.1
GET /get_image?file=../../../../etc/passwd HTTP/1.1

RESTスタイルのWebサービスでは、URIのパスの使い方が変わってきている。以前であれば、次のような形で検索条件を与えていた。

GET /query_sales?quater=4&year=2011&division=03  HTTP/1.1

RESTスタイルにおいては、例えば、次のようなパス表現を用いる。

GET /div/03/2011/Q4/sales  HTTP/1.1

URIパスの部分を用いて対象を一意に識別する仕組みがあると、サーバが提供するリソース群を、階層化されたデータモデルとして捉えることができる。すなわち、クライアント側は、アプリケーション領域により専念できる。

XHR 2 と XDR

クライアントサイドマッシュアップ においては、サイト主催者の Web サーバからロードされてブラウザ上で動作する JavaScript コードが、異なるサーバの Web サービスを利用できる必要がある。

従来、JavaScript コードがその実行を終了させることなく、出身と異なるサーバへ HTTP リクエストを送ることは制限されてきた。すなわち、「同一源泉ポリシー（Same Origin Polycy）」 が堅持されていた。しかし、マッシュアップの必要に迫られ、近年では、各ブラウザがその制約を緩め始めている。

自分自身の出身とは異なるサーバへ HTTP リクエストを送ることを、ここでは「他源泉リクエスト（Cross-origin Request）」と呼ぶ。他源泉リクエストの処理に関して、ブラウザの実装には、ふたつの仕様がある。

• XMLHttpRequest level 2 (Mozilla)

  "XMLHttpRequest - Mozilla Developer Network"

  https://developer.mozilla.org/ja/XMLHttpRequest

• XDomainRequest (Microsoft)

  "ドメイン間要求 (XDR) の概要"

  http://msdn.microsoft.com/ja-jp/library/dd573303(v=vs.85).aspx

XMLHttpRequest level 2やXDomainRequestを用いて行われる他源泉リクエストでやりとりされるHTTPリクエストとレスポンスには、通常のHTTP通信には無いヘッダが含まれる。

送られるHTTPリクエストには、それが他源泉リクエストであることを素材サーバへ知らせるOrigin: リクエストヘッダが含まれる。

返されるHTTPレスポンスには、素材サーバ側が他源泉リクエストを受け入れた（もしくは、受け入れなかった）ことを通知するAccess-Control-Allow-Origin: レスポンスヘッダが含まれる。さらに別のレスポンスヘッダが付加されることもある。

多く使われているマッシュアップAPI

多く使われているマッシュアップ API には、Google Maps、Twitter、YouTube、Flickr 等がある。これらは、広く知られたネットワークブランドが、Web ページと並行して API も提供しているものである。

ひとつのネットワークブランドが提供する API は一組だけでない。例えば Google であれば、Google Maps、Google Search、Google App Engine 等、複数の種類の API を提供している。