サイトハック
「tinami.php」では、HTTP_Requestを利用して、サービスの要求と、結果の取得を行っています。サービスを提供しているWebサイトの構造を調べて、どう要求を出せばよいかを知り、結果のHTML文書は、正規表現を使って解析しています。
// tinamiに接続するURLの生成 $tinami_url = "http://www.tinami.com/search/result.php?disp=50&word=" .urlencode(mb_convert_encoding($_GET['keyword'], "EUC-JP", "auto")); // tinamiに接続 $http_client->setURL($tinami_url); if(PEAR::isError($http_client->sendRequest())) { echo '<script language="JavaScript">document.getElementById("head")' .'.innerHTML="TINAMIへの接続が行えませんでした";</script>'; view_index("キーワード"); } // tinamiへの問い合わせ結果から、ググるサイトのURLを取得 $tinami_result = array(); preg_match_all( "/sitename\"><a href=\"\/cgi-bin\/launcher\?key=(.*)&URL=(.*)\" target/iU", $http_client->getResponseBody(), $tinami_result);
「TINAMI」はEUC-JPベースのWebサイトなので、キーワードをEUC-JPに変換し、URL引数に与えます。返された結果からは、WebサイトのURLを表現している部分を、正規表現で切り出して、あとで使えるようにしておきます。
返された結果の処理に関しては、正規表現を使う手法の他にも、HTML文書をパースして、DOM表現を得るやり方もあります。DOM表現を得る手法は、サービスAPIを使う場合にも行われる方法です。従って、DOM表現に統一することで、実装上のメリットが考えられます。しかし、情報を構造化して表現するXML文書に比べて、情報をどう見せるかが重要なHTML文書では、冗長な付加情報が多かったり、文法上のエラーが多かったりするので、DOM表現に向いているとは言えません。
このように、プログラムからWebサイトを利用する手法を「サイトハック」と呼びます。決して「サイトクラック」ではないことに注意してください。とはいえ、自動化によって、サーバへのリクエストが増え、負荷を高めるのは本意ではありません。
キャッシュでサーバに優しく
サービスAPIの中には、1日あたりのリクエスト回数を制限しているものがあります。無制限にしてしまうと、サーバの負荷が高くなってしまうと予想されるからです。サイトハックにもまったく同じことが言えるので、自らを律して、サーバに優しくしないといけません。そうした配慮がないと、サービス利用だか、サーバへの攻撃だか、分からなくなってしまいます。
「tinami.php」では、Cache_Liteを利用して検索結果をキャッシュしています。同じ結果を得るために、何度もサーバを叩くのではなくキャッシュを利用することで、サーバへの無用の負荷を避けています。
// キャッシュに保存 $web_cache->save(urlencode($content.'</body><html>'), $tinami_url);
// キャッシュの準備(pearモジュールが必要) require_once 'Cache/Lite.php'; $web_cache =& new Cache_Lite(array('automaticCleaningFactor' => 100)); // キャッシュを調べて、あったら使う if($content = $web_cache->get($tinami_url)) { view_index("別のキーワードで検索する?", FALSE); echo urldecode($content); exit; }
検索結果として表示するWebページの内容をキャッシュにセーブし、セーブしたものが見つかったら、それを表示に使っています。セーブの際にurlencodeしているのですが、これはCache_Liteの不具合で、日本語文字列をキャッシュできないからです。
ユーザーにも優しく
検索してみると、検索が完了するまで数分待たされることがあります。この間、待たされているユーザーは、本当に検索が進んでいるのか、不安にかられることでしょう。
「Web 2.0」には「Ajax」という、よりデスクトップアプリケーションに近い、非同期通信するユーザーインターフェイスをWebサイトに持たせようというコンセプトがあります。これはもともと、ユーザービリティの向上を意図したものです。「tinami.php」では、非同期通信こそしませんが、Javascriptを利用して検索の進行状況の表示などを行っています。
Webサイトを構築する基準として、「n秒ルール（3≦n≦8）」ということがよく言われてきました。数秒で表示されるようなWebサイトでないと、ユーザーにストレスを与えるというものです。しかし、ユーザーの入力を元に複雑な処理を行うと、数秒で表示させることは困難になります。そうした場合、なるべくユーザーが待ちやすいようにするしかないでしょう。
別の解としては、結果を後でメールで届けるという手法も考えられます。
「Web 2.0」の「マッシュアップ」と、「Web 1.5的マッシュアップ」の違い
「tinami.php」に見たように、「Web 2.0」で語られる特徴を利用することなく「マッシュアップ」は成立します。なんら新しい技術を使ったわけではありませんし、「サイトハック」アプローチも90年代後半には使われていました。では、「Web 2.0」の「マッシュアップ」は何が新しいのでしょう。
ここで「契約」というものが重要になってきます。サービスAPIの公開とは、特定の制限下で、決められた仕様によるリクエストとレスポンスを保障する、契約になっています。この契約に基づいて、「マッシュアップ」開発者にはサービスAPIの提供が保障される権利が生じます。一方、「サイトハック」アプローチの開発者には、保障がありません。Webサイトの構成が変化して、リクエストの方法や、レスポンスのHTML文書のデザインが変わっただけで、「Web1.5的マッシュアップ」は動かなくなってしまいます。
開発者の私的利用の視点から見ると、プログラムを修正する手間が度々発生する程度の違いですが、「マッシュアップ」サービスを商業目的で公開するには、安定運用が見込めるかどうかで、まったく違います。つまり、「Web 2.0」の「マッシュアップ」と、「Web1.5的マッシュアップ」の違いとは、ビジネスに乗るかどうかなのだと言えるでしょう。
ちなみに、現在、公開されているサービスAPIの利用規約のほとんどで、利用者側の立場はあまり強くありません。サービスが止まったり、変更されたり、なくなっても、責任は持てないと書かれています。結局、サービスAPI提供者と正式なビジネスパートナーになれないと、「マッシュアップ」サービスを維持するのは難しそうです。どちらかと言うと、アイデアとブランドを価値として買収してもらうことを期待して行う方向になってしまうでしょう。
さいごに
顧客や営業や上司がいくら呪文を唱えても、プログラムは出来上がりません。コードを書く皆さん自身が、本当に必要なのかを吟味して、中身を理解して使わないと、あまり良い結果にはならないでしょう。中身を見てみたら、既に皆さんがやっていることかも知れません。
概念を共有するのに、キーワードは重要です。しかし、意味が厳密に定義されないキーワードは危険です。「Ajax」は「Asynchronous JavaScript + XML」、非常に明確です。「Web 2.0」は……。
「マッシュアップ」は、アイデア次第で面白いものが作れますし、機能の実装をアウトソースしているので、コードも短く済みます。何か作りたいけど時間がない、長いコードは書きたくないという人にオススメです。
