English
アーカイブ
第8章 1.WebサービスとマッシュアップAPI
公開日：2007年6月28日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
マッシュアップとマッシュアップAPI
Webアプリケーションにおける「マッシュアップ」は、他者がWebサーバを通じて提供するソフトウェア機能を積極的に再利用することによって、自らのWebアプリケーションを少ない手間で構築することをいう。
マッシュアップの模式図を次に示す。
マッシュアップ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サービスには下記の特徴をもつものが増えている。
- アクセス対象 (リソース) を特定する条件を、URI パスの階層で表現
- リソースへ加える操作を、HTTP メソッドの POST、GET、PUT、DELETE の4種類のみで表現
- 送受信データフォーマットに JSON を使用
上記のうち 1，2 は、いわゆる「REST風（RESTful）」Webサービスの特徴である。例えば、操作対象のリソースは、
POST /jp/tokyo/bunkyo-ku/honkomagome/2/28 HTTP/1.1
のように、URI のパス階層を使って到達経路が示される。
RESTスタイル
「REST（Representational State Transfer）スタイル」は、Webサービス・システムのアーキテクチャ・スタイルのひとつである。RESTスタイルは、次の特徴を備えているとされる。
- ステートレスな通信プロトコルが使われる（サーバにおいて複数の呼出し間の状態が維持されない）
- ステート（状態）はクライアント側にロードされたリソースによって表され、リソースに含まれるハイパーリンクによって別のステートへ遷移できる
- リソースの生成、参照、書き換え、削除等のための操作セットがよく整理されている
- リソースは URI で一意に識別できる
REST では、Webサービス呼び出しを「リソースへのアクセス／演算」と捉える。その点が、「手続き呼出し」と捉える RPC、SOAP 等と異なる。「リソースへのアクセス／演算」と捉えることで、複雑な機能は記述できなくなるが、逆にそのことが Webサービスのインタフェイスのデザインをシンプルに保つことになり、他者からの利用しやすさをもたらしている。マッシュアップに向いたスタイルであると言える。
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)
- XDomainRequest (Microsoft)
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 を提供している。
表：多く使われているマッシュアップAPIトップ20
|
順位
|
API名称
|
機能
|
カテゴリ
|
APIを利用しているサイトの数※2
|
|
1
|
Google Maps
|
Mapping services
|
Mapping
|
2423
|
|
2
|
Twitter
|
Microblogging service
|
Social
|
752
|
|
3
|
YouTube
|
Video sharing and search
|
Video
|
652
|
|
4
|
Flickr
|
Photo sharing service
|
Photos
|
615
|
|
5
|
Amazon eCommerce
|
Online retailer
|
Shopping
|
416
|
|
6
|
Facebook
|
Social networking service
|
Social
|
387
|
|
7
|
Twilio
|
Telephony service
|
Telephony
|
353
|
|
8
|
Last.fm
|
Online radio service
|
Music
|
226
|
|
9
|
eBay
|
eBay Search service
|
Search
|
220
|
|
10
|
Google Search
|
Search services
|
Search
|
184
|
|
11
|
Microsoft Bing Maps
|
Mapping services
|
Mapping
|
175
|
|
12
|
Twilio SMS
|
SMS messaging service
|
Messaging
|
172
|
|
13
|
del.icio.us
|
Social bookmarking
|
Bookmarks
|
160
|
|
14
|
Yahoo Search
|
Search services
|
Search
|
144
|
|
15
|
Yahoo Maps
|
Mapping services
|
Mapping
|
135
|
|
16
|
Google Ajax Search
|
Web search components
|
Search
|
134
|
|
17
|
Google App Engine
|
Developer platform
|
Tools
|
122
|
|
18
|
411Sync
|
SMS, WAP, and email messaging
|
Messaging
|
120
|
|
19
|
Google Homepage
|
Portal gadgets
|
Widgets
|
101
|
|
20
|
Yahoo Geocoding
|
Geocoding services
|
Mapping
|
99
|
programmableweb（注釈1）から
表：多く使われているマッシュアップAPI のネットワークブランド トップ10
|
順位
|
ネットワーク ブランド |
提供しているAPIの種類の数
|
APIを利用しているサイトの数※2
|
|
1
|
Google
|
81
|
4112
|
|
2
|
Yahoo
|
40
|
825
|
|
3
|
Twitter
|
3
|
762
|
|
4
|
Amazon
|
18
|
667
|
|
5
|
YouTube
|
1
|
652
|
|
6
|
Flickr
|
1
|
615
|
|
7
|
Twilio
|
2
|
525
|
|
8
|
Facebook
|
7
|
459
|
|
9
|
Microsoft
|
9
|
233
|
|
10
|
Last.fm
|
1
|
226
|
programmableweb（注釈1）から
- 注釈1
- 出典：programmableweb
- 注釈2
- 2012年11月30日現在の数。この時点でprogrammablewebのサイトに登録されているマッシュアップAPI の数は8,056件、マッシュアップサイトの数は 6,851件あった。