excite Blog の API

HepCat Dev and Test: 業界標準を無視したエキサイトブログのXML-RPC
観測気球: exciteブログ、独自のXML-RPC API を実装!?

いろいろたたかれているようなので、alternative な意見も少し。誤解されるといけないので最初に書いておきますが、上記のような標準化を目指す意見と、それに反している戦略を批判する行動はとても貴重で、内容もおおむね同意です。ただ、サービスプロバイダ側にも事情ってものはあるだろう、と。そこを分析してみました。

結論からいうと Excite Blog が独自の API で XML-RPC のフロントエンドを実装したのは、（そこまで）非難すべきことではないとおもいます。ただし標準との互換性を（現時点で）放棄しているのと、API の仕様を一般に公開していないのはよくない点で、今後改善の余地はあるともいえます。

XML-RPC

現在の XML-RPC による Blog 投稿API のデファクトスタンダードである Blogger API, metaWeblog API ですが、ここに足りない機能を追加する場合、本家に拡張の提案をするか、独自のメソッドを追加するかになります。現時点で前者は非現実的。そうなると、

• 基本機能は Blogger, metaWeblog API を利用して実装して、足りない部分を exBlog.XXXX という拡張メソッドで実装する（Movable Type がこのやり方）。
• 全部を独自の名前空間で実装する。

のどちらかということになり、excite Blog は後者を選んだわけです。

前者のほうが「既存の Blog クライアントソフトウェアが利用できる」というメリットはありますが、どちらにしろ全機能を利用するにはクライアント側で拡張メソッドをサポートする必要がある。これは metaWeblog API のクライアントやサーバを実装したことがある方ならわかると思いますが、メソッドごとにシグニチャの順番が違っていたりしてかなりうっとうしいことになります。

だったら最初からクライアントもサーバも拡張メソッドだけで書いたほうが実装がシンプルになる、という判断でしょう。実装のシンプルさというメリットと、すでに普及している Blog クライアントが使えず（今回のケースでは ubicast しか使用できない）というデメリットをトレードオフではかりにかけた結果、後者を選んだということだけであって、これを非難するにはあたらないとおもいます。

AtomAPI (AtomPP) を使用しない理由

AtomPP (Atom Publishing Protocol) は現時点でまだ Draft 段階であり、不足している機能も多くあります。先行して Google の Blogger, Six Apart の TypePad / Movable Type, ライブドアの livedoor Blog は AtomPP を実装していますが、どれもベータであり、将来プロトコルを含めて変更になる可能性は大いに残されています（というかたぶん変わるでしょう）。

こうした不安定なプロトコルを今から実装して、変更のたびに追随してあわせるよりは、XML-RPC で独自に実装してしまったほうがメンテナンスコストは小さくてすむという判断なのでしょう。AtomPP が正式になったときに、現在の API とのブリッジをリリースするのでもよいでしょうし。

もちろん Google や Six Apart のように標準団体 (IETF) にも働きかけをしていく活動はすばらしいものですが、それをすべてのサービスプロバイダーに求めるのは現実的には酷なのではないでしょうか。

そして重要な点は、 excite Blog は Blog 界において Blogger や Movable Type のような「巨人」ではないという点です。Blogger や MT のような大きなサービス・プロダクトが、ユーザベースが多いという武器を片手に、独自プロトコルを推進することがもしあれば、それは非難に値しますが、そうでないんだから別に気にすることはないかな、というのが個人的意見です。

まとめ

冒頭で紹介した、この件を批判されている Blog はいずれも Blog クライアントソフトウェアを書かれている方なので、囲い込みにも見えるこの戦略に憤りを覚える感覚は理解できます。Blog ホスティングサービスとクライアントソフトウェア開発の関係は、こうしたオープンスタンダードな API の上に構築されてきたわけで、それを1つのクライアントが抜け駆けのような形で実装というのは確かにちょっと？という気はします。

しかし繰り返しになりますが、標準 API を実装しないことのデメリットをすでに excite Blog は抱えているわけです。ここであえてその API をリバースエンジニアリングして実装することは、その弱みをこちらでわざわざ消してあげることになるのですから、どうかなという気はします。

API ドキュメントの公開と、Blogger, metaWeblog で実装できる部分だけでもブリッジで対応することを要望するのは、ソフトウェアのユーザの声を味方につければ（容易ではないでしょうが）可能なことではないでしょうか。excite Blog が「巨人」ではないということはそういう意味で重要なポイントになると思います。