ここでは、Ajaxの存在意義について考えてみたいと思います。
それは、たった今(かなりの割合を斜めに)読み終わったムック「最新WebサービスAPIエクスプローラ ~Amazon、はてな、Google、Yahoo! 4大Webサービス完全攻略」が、Ajaxの存在意義を浮かび上がらせる非常に良い題材になったと思うからです。
ムックの目次 §
重要な意味があるので、目次を以下に引用しておきます。これで、何について書かれたムックであるか、だいたい想像できると思います。
- エントランス RSS&Atom徹底攻略
- ステージ1 Amazon Webサービス API徹底攻略
- ステージ2 はてな API徹底攻略
- ステージ3 Google API徹底攻略
- ステージ4 Yahoo! APIs徹底攻略
- ボーナスステージ1 Ajax徹底攻略
- ボーナスステージ2 Greasemonkey徹底攻略
このムックは面白いか? §
先に、これは書いておかねばなりませんね。
このムックを読んで、非常に面白く、わくわくしたのは紛れもない事実です。
実利性も極めて高いと思います。ここに書かれた内容のほとんど全てがインターネット上に存在する情報であり、印刷媒体が持つ宿命として内容に古びた部分があるとしても、それでも価値は非常に高いと思います。これだけの内容が、このコンパクトな1冊のムックに集約されているのは、右も左もよく分からない人が概要を素早く把握するために、とても価値があると思います。
ちなみに、私は断片的な知識を体系づけずに持っているだけで「右も左もよく分からない人」に該当するので、このムックを買ってみました。
おかげで、いろいろなことが非常に良く分かりました。断片的な知識がつながったし、知らなかったことも知ることができました。
という部分までが、いわば読書感想文。
本論は、ここから始まります。
この書籍の構成は壊れている…… §
結論から言えば、この書籍の構成は壊れています。
もう一度上の目次を眺めてみて下さい。
この書籍は、主に入り口となる「エントランス」と4大Webサービスを紹介する4つの「ステージ」から構成されます。
当然、「エントランス」というのは、4つのステージを読むための有意義な前提知識を与えてくれるもの……と思うかもしれませんが、そうではありません。
実は、「エントランス」に書き記された「RSS&Atom徹底攻略」で学んだRSS&Atomの知識は、「ステージ2 はてな API徹底攻略」では全面的に使われるものの、その他のステージでは出てきても小さなトピックでしかありません。
実は、この書籍の真の対立構造はSOAP対RESTにあります。
「ステージ1 Amazon Webサービス API徹底攻略」では、誌面のかなりの割合を割いてこの2つの相違を説明し、Amazon Webサービスが双方に対応する理由について(かなり歯切れ悪く)述べています。
また、「ステージ4 Yahoo! APIs徹底攻略」では、「ステージ3 Google API徹底攻略」で紹介されているGoogle WebサービスがSOAPを採用したのに対して、Yahoo!はより簡単なRESTを採用していることが強調されています。
これは、以下のような問題を引き起こします。
たとえば、Google Webサービスのことを知りたいと思った読者が、「エントランス RSS&Atom徹底攻略」を必須予備知識だと思って読んだとすれば、それはほとんど役に立たないということです。しかし、このような読者にとって、「ステージ1 Amazon Webサービス API徹底攻略」に書かれたSOAPとRESTの相違は有意義かもしれません。しかし、見出しを見て関係ないと思って読み飛ばすかもしれません。
つまり、このムックの本来あるべき構成を考えるなら、エントランスに位置づけられるのはSOAP対RESTであり、RSS&Atomは「ステージ2 はてな API徹底攻略」の冒頭に位置づける方が読みやすいと言えるかも知れません。
ボリュームという点でも崩壊している §
実は、エントランスとステージの割合は、極めてアンバランスです。
以下にページ数を並べてみます。
67ページ エントランス RSS&Atom徹底攻略
37ページ ステージ1 Amazon Webサービス API徹底攻略
26ページ ステージ2 はてな API徹底攻略
26ページ ステージ3 Google API徹底攻略
13ページ ステージ4 Yahoo! APIs徹底攻略
エントランスの内容は、(このムックに限れば)今ひとつ役に立たないにもかかわらず、67ページと割合が突出しています。逆に、各ステージの中で、ステージ1だけページ数が突出しているのは、やはりSOAPとRESTの説明を行っているためだと思われます。
念のために言えば、「RSS&Atom徹底攻略」の記事内容は、けして悪くないと思います。それは意義がある内容だし、読む価値も大いにあると思います。問題は、その記事が置かれた場所であると言えます。
更に混乱するボーナスステージ §
話をボーナスステージに拡大すると、更に混乱が見えます。
「ボーナスステージ2 Greasemonkey徹底攻略」については、ここでは取り上げません。
ここで取り上げるのは、「ボーナスステージ1 Ajax徹底攻略」です。
さあ、ここでのメインディッシュとなるAjaxの登場です。
実は、Ajaxは、本来の定義通りにXMLHTTPRequestを使って通信を行うとすれば、4大Webサービスを直接呼び出すことができません。XMLHTTPRequestには以下の特徴があるからです。
- SOAPはサポートしない
- セキュリティの制約上、他のドメインと通信することができない (通常、サードパーティーや個人が作成したAjaxプログラムは、4大Webサービスのドメインには設置されない)
いや、そんなはずはない……。事実、Amazon ECSを使ったAjaxのサンプルもあるではないか……と思う人もいるかもしれませんが、おそらくそれは「そのままでは動かない」かあるい「サーバ側の助けを借りて実現している」のだろうと思います。
つまりですね。
この書籍の「ボーナスステージ1 Ajax徹底攻略」の内容は、明らかにこのムックの主題である4大Webサービスの話題と噛み合っていないし、整合させようと言う努力も感じられないのです。
なぜ目次構成は崩壊したのか §
目次構成が崩壊した理由を考察することは、なぜAjaxが必要であるか、その理由について考えることにつながることに気付きました。
まず、なぜRSS&Atomが冒頭に来て強調されねばならないのか。その理由は、おそらくマーケティング的なものでしょう。多くの大企業がこれらを採用し、大きなビジネスになると喧伝されています。それゆえに、RSS&Atomについて読みたい読者も多いだろうし、それが重要なテーマであると認識するのは自然な反応だと思います。
SOAP対RESTという構図は、それと比較して、話題性に乏しいと言えます。宣伝に金を使う大企業の多くはSOAPを支持しています。メディアもSOAPの明るい夢物語を描く機会は多いですが、RESTとの対比でSOAPの抱える問題点を暴くようなことはあまり行われません。
しかし、Webサービスの世界とは、まさにSOAP対RESTの闘争の現場であり、ここに足を踏み入れるなら、それを避けて通ることが出来ません。
一方、新しい価値を創出するために最先端の激闘を戦っている4大Webサービスの世界で、標準化された共通APIを待つなどという選択はあり得ず、必然的にインターフェースは独自に定義されるのが必然的な流れとなります。つまり、4大Webサービスの世界では、RSS&Atomでは記述できない新しい情報を扱うことが当たり前であるために、RSS&Atomの存在感は小さなものにしかなり得ません。
余談ですが、このような構図の中にあって、はてなだけがRSS&Atomを全面的に活用していることは、特に注目に値すると思います。なぜAmazon, Google, Yahoo!の3者にできない標準フォーマットの全面採用が、はてなにおいてのみ可能となったのか。それついて考えることは面白チャレンジになると思いますが、本論ではないのでここで終わります。
つまり、世間とWebサービスの現場の温度差が、必然的に目次構造の崩壊をもたらしたと言えるかもしれません。
Atom APIを採用できるか? §
「エントランス RSS&Atom徹底攻略」を読んでいて思ったのは、Atom APIの可能性です。非常に大ざっぱで間違った要約をするなら、これはブログに書き込むためのリモートAPIです。
私が特に驚いたのは、既にAtom API対応のブログに書き込むためのツールが存在することです。
ならば、メーリングリストを扱うりすと亭や世間からはブログと見られることもあるMagSite1にAtom APIを付けて、このような既存ツールで書き込めるようにしたら面白いのではないか……、と思ったわけです。
本来無関係に作られたソフトが、何らかの標準を介して接続する面白さは、なかなかに麻薬的な楽しい味があります。
が、しかし、これは無理があるという結論に達しました。
(以下は、厳密にチェックしていない現時点での思い込みに過ぎないことを断っておきます)
Atom APIやそれをサポートするツールは、それが想定するデータ構造を持っています。
りすと亭やMagSite1は、そのデータ構造と食い違いを持ちます。多くの部分では共通の情報を持つでしょうが、微妙な部分で不整合が起きます。当然のように送られてくる情報を受け止めるための項目が無かったり、あるいは必須とも言える情報を送信する能力がなかったりするでしょう。
後者は、言語(フォーマット)に独自モジュールを追加することで、おそらくは解消できるでしょう。そのような意味で、仮にりすと亭やMagSite1にAPIを追加する場合に、Atom API+独自モジュールという構成を取ることは、もちろん「あり」です。それは1つの有効な戦略でしょう。
しかし、言語が拡張可能だとしても、ツールも自由に拡張できるわけではありません。ツールを拡張するには、おそらくプログラムの修正が必要でしょう。修正しても、それは特定ソフト専用の機能ということにしかなりません。ツールの作者が、単なる思いつきの遊びへのサービスとして、そのような拡張をやってくれるとは思えません。仮にツールのソースが公開されている場合に、自分で修正を行うかというと、おそらく大手術になるので、やはり無理でしょう。
では、りすと亭やMagSite1のソフトのデータ構造の方を、Atom APIに合わせるという選択はどうでしょうか?
それは全くもって不可能であり、非現実的な提案であると言えます。なぜなら、それらのソフトは、様々な外的要因と、ニーズに対する要求から機能性が規定されていて、それを変更することは期待される機能性の一部が欠落し、過去のデータとの互換性を失うことを意味するからです。
というわけで……。
Atom APIを実装しても面白い遊びにならない……、という結論に至るのです。
3大Webサービス §
4大Webサービスのうち、標準を採用するはてなのみを例外として除外した残り3つを、ここでは3大Webサービスと呼ぶことにしましょう。
3大Webサービスは、それぞれに、独自の機能性を持ったサービスを持っています。
これらのサービスは、様々な理由から様々な機能性を持っていて、それを単純に標準化することはできないでしょう。
もちろん、大多数の機能は共通の機能としてまとめられるかもしれません。しかし、全ての機能は標準化できないでしょう。そして、標準化できない機能の中には、差別化という観点から必須に要請される機能が含まれる可能性が高いと思います。
つまり、3大WebサービスのAPIは標準化できず、それらを扱うソフトは個々のAPIに対する専用クライアントにならざるを得ないのです。
この構図は、実は3大Webサービスに限定される訳ではなく、差別化のため、独自性を発揮するため、特定のニーズに適合するため、過去のしがらみとの互換性のため、等々によりどうしても割り切れない機能性を持つ全てのソフトやサービスが該当します。もちろん、りすと亭やMagSite1も、これに該当します。世の中の過半数のソフトやサービスは、おそらくこれに該当すると思います。
それにも関わらずRSSが成功したのは…… §
余談ですが、それにも関わらずRSSは非常に多くのソフトやサービスが採用でき、普及した理由は、それが事実上「新着記事の通知」というシンプルな役割に限定されたためでしょう。単に伝えるだけなら、さほど細かい機能性に対する要求も出ないでしょう。しかし、通知されて読みに行く記事の内容について、きめ細かく標準化を行うとなれば話は変わります。それこそが差別化の主戦場であり、おとなしく標準化が達成されるとは思えません。また、より良い使い勝手や機能を求める利用者の立場からすれば、標準化によって改善が遅れたり、不可能になったりすることは本末転倒と見る視点もあり得ます。
専用クライアントの問題 §
仮に、各サービスごとに専用クライアントを作らねばならない、という結論を肯定するなら、それは非常に悩ましい問題を発生させます。
3大Webサービスの場合、専用クライアントを作った場合にそれを利用する可能性のある人数が極めて大きいため、開発しようというモチベーションも上がるでしょう。
しかし、名も知られていないマイナーなソフトやサービスに対する専用クライアントを喜んで作る人がどれほどいるでしょうか?
おそらく、誰かが作ってくれることを待っていても、誰も作ってくれないでしょう。
やはり、ソフトやサービスを提供する側で作らねばなりません。
ここで、ユーザーインターフェースを提供する専用クライアントに限って話を進めましょう。
素敵なソフトやサービスとワンセットで専用クライアントを作るとしたら、どのような技術を選択するのが最善でしょうか?
専用クライアント自主開発の条件 §
3大Webサービスほどメジャーではない立場で専用クライアントを自主開発するとすれば、それは以下の条件を満たさねばなりません。
- 最小の開発コストで、最大の成果を得られる
- 作成するクライアントの種類は少ない方が良い
- 利用できるユーザー数は多い方が良い
- 配布、バージョンアップのコストが低い
- 配布、バージョンアップが誰でも容易にできる
これまで、これらの条件を全て満たす手法はなかなか得難かったと言えます。
利用環境が限られたり、特定のソフト、プラグインのインストールが要求されたり、様々な制約があったと思います。
結論としてのAjax §
実は、ここでAjaxの存在意義が強く浮上してきます。
Ajaxは上記の条件を全て満たします。
- たった1本のプログラムで、OSの種類に関係なく、主要なWebブラウザの全てで実行できる
- ゆえに、利用できるユーザー数は非常に多い
- 配布、バージョンアップのコストはゼロに等しい
- 配布、バージョンアップは単にそのページにアクセスするだけで完了し、誰でも容易にできる
以上を結論としてまとめます。
特定のソフト、サービスに対応する専用クライアントを、最も高いコストパフォーマンスを達成しつつ実現し、最も手軽に利用できる手法がAjaxである。特に、配布、バージョンアップの低コストさと容易さは、他の追従を許さないほどに優れている。
もっとも、Ajaxは開発の難度が高いのは事実なのですけどね。ブラウザ間の非互換性や、非同期通信プログラミングの難しさ、というハードルは確かにあります。しかし、これらは解決可能な問題でしょう。
標準の呪縛を解き放て §
RSS&Atomから始まってAjaxに至る長い旅をここに書いてみたわけですが……。
実は最後に付記しておくべきことがあります。
それは標準化が常に素晴らしいわけではない、ということです。
標準化は、それに必要な資質が全て出尽くした枯れた技術か、あるいは標準化しなければ始まらないテーマに関してのみ行う価値があります。
たとえば、まだ誰も実現していないサービスで使用するフォーマットを標準化しよう……、という試みは失敗することが多いのです。誰も始めていない段階で標準を決めて、皆でそれを守れば、とても素晴らしい未来になるだろう……という予感は必ずしも間違いではありません。しかし、事前に何もかも見通せるほど人間は賢くありません。やってみる前に決めた標準が、実際の活動において理不尽な制約として機能した事例もけして少なくありません。
ということは、どういうことかというと。
ある通信フォーマットに必要とされる資質は、事前にその分野に関する実績があるのでない限り、運用してみるまで確定できないということです。
特に、新しいサービスを志す場合は、事前に確定できないのが当たり前だと思った方が良いと思います。
ゆえに、運用開始後に、通信フォーマットは変わると考えることが健全な態度でしょう。
実は、ソフト、サービスと専用クライアントをワンセットで開発、提供するという方法論は、通信フォーマットをいつでも改善できるという意味で、このような状況に非常によく適合するのではないかと思うのです。
このような方法論を仮に「変化を抱擁する通信フォーマット主義」略して「変化通信主義」とでも呼んでみましょうか。
この主義は、標準を定めることを「当然の前提」とする全ての方法論と対立します。
そして、この対立は実は奇妙にねじれた構図を生み出します。
たとえば、SOAP対RESTという対立構造がありますが、「変化通信主義」的な立場からすれば、固定した(変化しない)通信フォーマットを指向しているという点で、いずれも「変化を抱擁しない」という点で1つのカテゴリにくくって「敵対者」というレッテルを貼ってしまうという選択もあり得るのです。(これについては、異論があり得る)
宿題 §
誰に対しての宿題だ?
通信フォーマットのリファクタリングについて検討せよ。
書く前には思ってもいなかった「変化を抱擁する通信フォーマット」などという言葉を書いてしまったので、こういうテーマが浮上してしまいました。とほほ。
