HepCat Dev and Test

Atom API vs XML-RPC

Blogエディタを開発中であるわけなのですが、 （このエントリーもそのBlogエディタで書いているのは秘密です）結局AtomAPIではなく今の所はXML-RPCでいこうかと思います。 本来はAtomAPIで行きたかったのですが、これや諸般の理由により AtomAPIの実装はとりあえず断念します。

以降、何かの足しになればと思い公開するものであり、技術的詳細やら長話に興味がない方には申し訳ありませんが あまり興味のある話ではないかと思いますのでご了解ください。 （とか言いつつ、Blogエディタのテストがしたいだけじゃないのかという話も聞こえる）

改めてですが、Blog本体と通信し更新などの処理を行なう方法で今現在一般的なのは、XML-RPCと言われるものです。 大抵の（と言っても少ない）BlogエディタはXML-RPCで実装されていて、クライアントソフトウェアーサーバー間の 通信にXML-RPCが用いられています。

しかし、個人的に前からどうせ作るのならXML-RPCではなく、Atom APIでと思い一人去年から騒いで (..) (..) いたのには理由があります。

Blog関連に絞ったウェッブ上のリソース管理パブリッシングプロトコル（長い）として非常に強力であると認識したと同時に 現行の方法では解決できない問題を幾つか解消しつつ新しい機能を実装できるからです。 以下、つらつらとAtomAPIについて、またXML-PRCとの簡単な比較などつらつらと書いて見ます。

国際化について

・XML-RPC
ちょっと前まで、仕様により文字列に日本語などのマルチバイトを使用出来なかった。 また、日付のタイムゾーンの指定が仕様で明示的に禁止されているため、混乱が起きやすい。
・ATOM　API
多分問題なし。

拡張性について

・XML-RPC
データ型の規定が存在する。利用できるメソッドを指定できる。 そのため、汎用性があるが、拡張性に乏しい。 元々は名前が示す通り、リモート呼び出し手続きに利用される。
・ATOM　API
ウェッブコンテンツ更新等のために今現在裁定されつつある新しい規格。 名前空間を利用したりして、拡張するのが容易。

セキュリティについて

・XML-RPC
セキュリティ特に決められていない（？）。 今現在、Blogなどを更新するケースでは、パスワード自体が（暗号化せずに）平文で送信される。 （ブラウザーでの更新も同じ）
・ATOM　API
SHA1で生成した、160ビットのハッシュ値を送るため安全性が高い。 生成されたハッシュ値からパスワードを得るのは現在の所、不可能。

より細かい比較、というかAtomの利点については、本家SixApart社のページ（英文）を参照ください。 Why We Need Echo (EchoとはAtomの旧名)

付け加えるべき利点といえば、もうだいぶ解消されてきた模様ですが、 TrackBackの文字化けも、対症療法ではなく原因から根本的に解消されます。

ずいぶん前に書いたATOM関連のエントリー
Atom and Its API

更新PingやTrackBackPingが実装されてればそれでBlog完全対応！で終わらせられるのがちょっぴり 残念で、出来れば多くのBlog関連のサービスやツールが、少なくともXML-RPC、できればAtomAPIの実装にも 力を入れていただきたいと思うこのごろでした。

Posted by HepCat at May 18, 2004 05:55 PM | TrackBack