Web API: 2005年12月アーカイブ
今日宮川さんに聞いたFlickrの耳眼コピサイト、Livedoor Pics。でもAPIはAtom PP 0.3でWSSE認証だぜってことで、宮川さんに言われるまで忘れていた拙作のAtom API Photo Uploaderを早速テスト。
はい、何もいじらずにポストできましたとさ。LivedoorさんGJ！
Build 5270でようやくここで書いた機能が一通り揃った。
・Simple List Extenstionsの実装
こんな感じのSLX付きRSSを読ませると、画面のように任意の要素の値による絞り込み（ここではgenre要素）と任意の要素の値でのソート（ここではfirstedition要素）ができる。
・OpenSearch 1.1での検索エンジン追加
OpenSearch 1.1仕様のDescription Documentを用意しておけば、任意の検索エンジンをワンクリックでIE7画面右上の検索エンジンボックスに追加できる。ちょっとmiyagawaさんのBulkfeedsを題材にやってみた。
- OpenSearch 1.1のDescriptionを用意する（Bulkfeedsには1.0のものが用意されているけど、これを読ませてもエラーになった）。
- AddSearchProviderを呼び出すJavaScript入りのページを作る。
- IE7で２のページのリンクをクリック。
画面が出てきたらAdd Provider。
検索エンジン追加。- 検索可能。やったね！
ところでIE7のメニューに組み込まれている「Get Search Providers...」をクリックすると、Windows Search Guideってページに飛ぶんだが、ここには今のところAOLとAsk JeevesとMSNが並んでるだけ。なぜAOLがトップなんだってのも意味深なら、GoogleやYahooが出てないけどAskは出てるってのもなんだかなー。
Yahoo.comの検索ボックスにショートカット機能が追加されました。
例えば!amazon sum 41と入力すればAmazon.comでsum 41の検索結果が表示されるってわけです。!flickrなんてショートカットも登録してあります。Flickrのタグで検索した結果へ飛べる。「!flickr tokyotower」みたいな感じ。
でこいつの肝は自分のショートカットをYahoo!.comに覚えさせることができる点。
例えば「!set g http://www.google.co.jp/search?hl=ja&q=%s」 とやって検索すれば、次回からは!g movable typeとやるだけでGoogle日本のmovable typeという検索の結果ページに飛べるってわけです。
せっかくGPS機で走りながらログを採ってるので、後で楽しめないかとGoogle Mapsしてみた。右の絵をクリックするとFlashで雰囲気が見られます。なかなか楽しい。
Being understood that their primary goals have already met, Microsoft, IBM and SAP will stop operating UDDI Business Directory. OK, one down, two to go
テストの目的は達したとのことで、MS、IBM、SAPの３社はパブリックに運用していたUDDI ビジネスディレクトリをシャットダウンするそうです（http://www.uddi.ne.jp/はどうすんの？）。残りはあと２つですねｗ。
WSDLはどうなんですかねー。今のままのWSDLをRESTに流用するのは問題アリだと思いますけど。Atom PPなスケルトンの元になるWSDLみたいなもの＋その実装って誰か作ってるんだろうか。スキーマ定義してWSDLのHTTPバインディング使えばいいの？よくわかんないな。
GoogleがHomepage APIということでガジェットを入れる機能を公開した模様。ただし、start.com/live.comと違って誰でも何でも追加できるわけじゃなく、GoogleにsubmitしてGoogle側で登録してもらわないといけない。hmm...<-コメント参照。@akaさんthx!
Alexa Web Search Platformがベータ公開された。さすが、サイボウズの秋元さんがすでに詳しいエントリを公開されていて、ほとんど追加すべきことなんかない（し、秋元さんはまだ記事を追加されるみたいな）んだけど、一点だけここは見落とせない！点を。
データを開発者に公開するというのはもっともな視点なんだけど、開発者に公開するという点では最後に見逃せない項目が、上でリンクしているAlexaの公式ブログにあるサービスの特徴の箇条書きにある。
> ・Access your new search via Amazon Web Services
そう、AWSのプラットフォームを使って、「あなたの検索アルゴリズム」を、「XML/Webサービスとして」公開できるということだ。
Alexa Web Search Platformによって、Alexaが持つ帯域幅と膨大なクロールデータを利用できる。AWSプラットフォームによって、膨大な量のリクエストを処理できるWebサービス処理エンジンを利用できるようになる。あなたが作るのは検索アルゴリズムだけ。RESTとSOAPの両対応やら24x7での運用など、その他のheavy liftingはすべてAlexaとAWSがやってくれる。ある意味、大規模なning.comといえる。AlexaのサービスとHPSを通じて、すでに課金の仕組みを用意している点も見逃せないだろう。Alexa Web Search PlatformでPlatformIdごとの課金ができるのかはわからないが、いずれ「あなたの検索アルゴリズム」のユーザーに対して「あなたが」課金できるようになるに違いない。
Amazon Web サービスがやろうとしているのは、ECSのようなサービス自体の提供だけではない（ある意味で、ECSもAWSプラットフォーム上で稼動するイチお客さん）。Webサービスを稼動させる環境そのものをAmazonで担おうとしているのではないだろうか。
Permalinkのサマリーが欲しいならmeta descriptionでいいんじゃないの。Auto-Discoveryなんかしなくたって、headを読んだ時点でdescriptionが手に入る。たかがサマリー取得のためになぜ2度もページ（とそのメタデータ）を取得しなければならんのだ。meta descriptionってなんかうぇぶ２．０っぽくないから流行らない？microformatsって言えばいいじゃん。ブログサービスはmeta descriptionをちゃんと記述しる！ってことでいいんじゃないの？
RSS 1.0ってRich Site Summaryって名前なんだし、サイト（＝channel）についてのメタデータなのだから、どこのPermalinkからアクセスされようと、メインのページのサマリー、つまり最新ｎ件を表示するってのは理にかなってるよね。RSS 1.0を使ってサイトの各ページ（＝channelから配信される各item）のメタデータだけを記述しようとするのって変じゃない？変というより、それってRSS 1.0が表現する意味合い（semantics!）とは違うんじゃないかな。RSS 2.0についてもその辺の違和感（itemのメタデータなのにchannelについて語る「フィード」を取得するっていう違和感）は共通してるなぁ。
もしどうしてもダメな理由があるのなら、水谷敏行さんの案の方に一票だなぁ。itemについてのメタデータなんだからitem要素だけがあるべきだよ、うんうん。ただ、この程度の用途であんな巨大なRDFメタデータを作る必要があるのか、甚だ疑問だけど（RDFが嫌いなだけとも言う）。
でも、Atomだと話が違ってくるかなぁ。Atom SFってまんまHTMLのalternativeのような気がするので、Permalink（HTML）のalternativeとして（これ重要；metaではない）ほぼ同じ内容のatom:entryが返されるURLをlinkするってのはアリな気がする。もちろんこれはAtom Entry DocumentであってAtom Feed Documentではないのだけれど。
そういうわけで、live.com/start.comに入れて使う便利ツールガジェットを作りました。
まあ誰が使うんだって話ですけど（ｗ
