お問い合わせ
会社概要 ソフトウェア 開発ブログ サポート

« 2006年02月 | メイン | 2006年04月 »

2006年03月27日

Re: MT 3.2のAtom API

トラックバック頂きまして、MT3.2でのAtomAPIがBlogWriteで正しく動いていないという事気が付きました。MT3.17では、問題ありながらもとりあえず動いていはいたんですが...。

結論から言うと、MTでの利用に限って現時点では今まで通りXML-RPC APIを使って頂きたい、という所です。(過去の経験からTypePad含むMTのAtomAPIは日本語周りとか色々問題があったため)

けれども、MTでAtomAPIが動くに越したことはないので、Ogawaさんの方法で、MTのAtomServer.pmの一行をコメントアウトして、動作検証して見た所、Ogawaさんのご指摘どおり、過去記事の取得を除けば、日本語周りも含めて動くようになりました。

で、なぜ過去記事の件が取得は出来ていながらBlogWriteで上手く行かないのか、という事ですが、

例1: 
<content mode="xml">
   <div xmlns="http://www.w3.org/1999/xhtml">asdfasdfasdf</div>
 </content>

コンテンツのmodeがXMLとなっているのですが、コンテンツのTypeが指定されてないため、デフォルトのtext/plain扱いになります。で実際はDIVで括ったXHTMLなので、Text扱いすればよいのかXHTML扱いすればよいのか分からず正しく編集出来ません。なので下のように、XHTMLなら、"application/xhtml+xml"のように指定するのが吉。
 
<content mode="xml" type="application/xhtml+xml">
   <div xmlns="http://www.w3.org/1999/xhtml">asdfasdfasdf</div>
 </content>

例2:
<issued>2006-03-06T13:41:18+0900</issued>

日付変換処理で落ちまくっている、と思ったら、MTが返す日付が上記のように、タイムゾーンオフセットが、+0900になっていました。RFC3339の仕様、詳しく読んでいないけれど、普通は、下記のように、コロンが必要なんではないかな、と思います。ここで落ちているため、処理が止まってしまってました。

<issued>2006-03-06T13:41:18+09:00</issued>

あともう一つ。日本語のコンテンツがすべてBase64でエンコーディングされている気がします。確かに仕様ではBase64指定出来るとあるけれど、これは本来バイナリーのアップロードに使うものじゃなかったのかっ?というツッコミも一応。BlogWriteは一応Type属性でtext/htmlとか,plain,xhtmlに指定されてた場合のみ、Base64もデコードしてます。

参考:旧AtomAPI仕様ドラフト

で、一応なんですが、そろそろ、この旧AtomAPIはObsoleteになりつつあります。 ベンダーとしては、今この旧AtomAPIにリソースを割くよりは、現在IETFで議論されている、The Atom Publishing Protocol のサポートに注力すべき頃だと思います。
参考:
The Atom Syndication Format (RFC4287),
The Atom Publishing Protocol (draft-08)

IETFワーキンググループでの現状ですが、今はAtomPPのクライアントとサーバーによるInterop(相互運用性)テストを行なっているフェーズで、この結果を元にさらに、仕様をリファインしていく段階です。もうすぐ仕様は完成か、と言われると、微妙です...。大体出来たけど、まだまだやること残っている、といった所でしょうか。

当然のことながら、BlogWriteでもこのAtom Publishing Protocolをサポートすべく、積極的に動いたり、IETFでのMLとかでも最近はアクティブに参加してます。

投稿者 BlogWrite担当 : 14:10 | コメント (0) | トラックバック

2006年03月06日

RESTなWebAPIの開発支援ツール

技術者向け記事です。ご興味ない方には申し訳ありません。

ちょっと前になりますが、RESTのAPIを開発する上で便利かもしれない社内製ツールを公開しました。5年ぐらい前に学習目的で作ったXMLエディタとBlogWriteの通信部分をくっつけてゴニョゴニョとやったものです。

因みに、「The Future of Web Apps」 Webアプリの未来 - と題したコンフェレンスのポッドキャストをやっと消化し終わりました。

このコンフェレンスでは、Googleマップの開発者、米Yahooの人、Ruby on Railsの人、Delicious、Flickr、などなど最近の代表的Webアプリケーション開発者が集まった豪華なメンバー..。どの話にも共通していたのは、やっぱり、APIの事でした。OpenなWebサービスAPI重要。

The Atom Publishing Protocolもある程度形になってきましたし、日本でもRESTについて、APIについてそろそろ盛り上がってきたこの頃、皆様いかがHackしておられますでしょうか。

自分がAPIのサーバー側を作ることになって気が付いたのが、API自体の設計や開発、テストをする上で面倒な事は、サーバー側のアプリケーションとクライアント側アプリケーションを両方作らなければならない、という事でした。サーバー側を作ってテストするには、クライアントも同時に作らないと行けません。インターオペラビリティを確保するためにも、第三者が作ったクライアントがあった方が良いです。ところがクライアントは、世の中に存在していないAPIに対応したり、サーバー側アプリケーションが動いていない中ではどうしても作りにくいものです。まさに鶏と卵。

では、汎用的なRESTfull APIクライアントがあれば、Web APIを実装する際、特にサーバー側で実装する際、色々と便利ではないでしょうか。ブラウザではGETは出来てもPUTやDELETEは出来ませんし、ヘッダー周りや内容を変更する事は難しいです。

そこで、POSTやPUTする場合、Bodyに含めるXMLを予めファイルで用意しておけば、後は随時、任意のXMLを開いて一発で指定したメソッドでHTTPリクエストを発行し、ヘッダを含むレスポンスも確認出来るようにしました。ついでにXML編集機能がありますので、設計段階から使えます。

もともとXMLエディタだったものをベースにしているので、POX(Plain Old XML)の作成編集、XSLTの作成編集プレビュー機能などもあり、Atom,RSSのGET、AtomAPI(GET,POST,PUT,DELETE)のテスト、XML-RPC(POST)のテスト、OPMLも直に読み書き(GET,POST)できるようにしました。

XMLを脳内変換出来る人はこれだけで、ウェブのRead/Writeが実現(w)、ブラウザいらず..というのは冗談です。

もしご興味がありましたら、
http://www.witha.jp/eXeries/ja/
からご自由にどぞ。 

追記:(2006/03/09)
英語版のページも作っておいたら、早速「ある本の著者なんだけど、スクリーンショット使ってもいいか」なんてメールが海外から来ました。楽しみ。

投稿者 BlogWrite担当 : 19:52 | コメント (0) | トラックバック

RESTという言葉の誤用について

あまり表立って、REST自体の事を詳しく書いてこなかったのですが、実は2003年頃から一歩引いた所からRESTには注目してきました。実際AtomAPIを知ったのもREST繋がりです。

最近、XML開発者の日を境に、RESTというアーキテクチャスタイルが日本でも広まりつつあるのですが、ちょっと誤用が増えてきた気もしないでもありません。

HTTPリクエストを使って、XMLが返ってくるものを何でもRESTと表現されてしまい、結局意味がバラバラで、バズワードのように濫用されるのではという懸念も一部ではあるようです。

実際、誤解を広げかねない説明をしているサービスもあります。 一例を上げると:

「REpresentational State Transferの略語。HTTPリクエストに対してXMLをレスポンスとして返す。********WebサービスはRESTを採用しています。」

HTTPリクエストを使えばRESTというわけではなく、URIとHTTPメソッドを正しく使う事が主眼Uniform Interface が重要であり、また、あまり知られていないのが、POSTのボディやレスポンスのボディは別にXMLである必要性はまったくない、という事です。ブラウザがバイナリチャンクでもステータスコードのみでもOK。XMLはしっかりと規格化されていて汎用性があるフォーマットだから多く利用されるだけです。 (例えばブラウザーが画像(リソース)をGETしてバイナリーで受け取った場合の振る舞いはRESTfullと言える。HTMLのページでも同様。ただ、ブラウザは通常POSTかGETしかしないのが問題。RESTを一言で言うと、本来のWebの用法に従うということ?)

なので、上記のREST定義は誤解を広げかねないと言えます。

ここで行き違いが生じやすいのですが、「POSTとGET、PUT、DELETEなどを使え」、と強制している訳でも、「RESTという言葉を使うな」、といっているわけでもないのです。単に言葉は正しく使いましょう、という事だったりします。 あえてRESTでない手法を選択したのであれば、それはそれで構わないでしょう。しかし、実態は異なるにも関わらずRESTと称するのは健康的ではない、というのが私の考えです。

つまり、 自動車を無理やり線路の上を走らせることが出来たとしても、それを電車とは呼びません。ただ「線路上走行自動車」でしょうか... これに準じて先の定義は、あえて言うなら、RESTでなく、「POX over HTTP」ぐらいにすべきでしょう。

「Web2.0」といった概念を表す言葉とは異なり、RESTアーキテクチャスタイルには、しっかりとした指針(UCIでの論文)があります。もしWebリソースの作成含めてすべてのHTTPリクエストにGETを使っていたら、それは正しくHTTPを利用しているとは言えず、RESTではないでしょう。

ウェブサイトのトップページを指す「ホームページ」が、いつのまにかウェブサイト自体のことを言うようになってしまったりしてますが、RESTという言葉が見当違いのことを指すようになったら、もっと困ってしまいます。私がもっとも懸念するのは、もし誤用が広まると、RESTというアーキテクチャスタイルを採用して健康的なWebAPIを作成しようという人たちが真の恩恵を受けられず、多大な迷惑を被ってしまいかねない、という事だったりします。

また、言葉だけで利点を理解するのは難しい時があります。ですから、実際にAtomAPIを利用するシステムを開発して見ると、本当のRESTと、そのリソースのURIに対し、POSTで新規作成、PUTで更新、という流れがシンプルで効率よく、設計が美しく感じられるようになるのではと思います。特にXML-RPCのような冗長で無駄の多い仕様を同時に実装して見ると、違いが実感出来ます。

関連情報:
REST 入門
REST の日本語リソース
ウィキペディア:REST
AtomAPI解説

変更履歴:
「アーキテクチャー」ー>「アーキテクチャスタイル」
「HTTPメソッドを正しく使う事が主眼」ー>「Uniform Interface が重要」
御免なさいm(_'_)m ビックル飲みまくり... 詳しくはhttp://yohei-y.blogspot.com/2006/03/rest.html

投稿者 BlogWrite担当 : 19:20 | コメント (1) | トラックバック

Trackback標準化の件

昨日のことなのですが、このブログに対して短時間の間に80件もの(英語の)トラックバックスパムを受け、その後も数時間に渡って続き、総数100件以上に達しました。

1日の内にこんなにまとめてTrackBackスパム攻撃受けたの初めてです。サーバーにかかる負荷を考えただけでゾッとします。(ロリポップサーバーよく頑張ってるなぁ)
もちろん、とりあえずの対策で、「言及なしTrackBackを拒否する」プラグイン(NaoyaさんThanks)を入れてますが、どうもそれも看破されたようです。やはりこのブログもMovableType3.2にアップデートする潮時かもしれません。問題はその時間が取れないという事なのですが...。

そこで、ちょっと前のTrackBackの標準化の件に改めて注目して見ました。

SixApartのTrackback規格をIETFの下でワーキンググループ作って、標準化しようという事で、企業の姿勢としてもとても素晴らしいと思います。だって、例えば某企業とかだったら、スパム対策用に別途有料ソフトを導入するように、なんて売り込みかねないですが、そうではなくオープンに議論して解決策を探るというのは評価すべきと。

で、ここら辺で、現状のドラフトとかを見れます。
http://www.lifewiki.net/trackback
メーリングリストにも参加してみました。

あまり詳しく読んでないけれど、ドラフト仕様では、国際化の件(文字コードの指定)が含まれているのが大きいですね。
あとAutoDicoveryの方法が増えて、RSSやAtomと同じ形式

<link rel="trackback"
           type="application/x-www-form-urlencoded"
           href="http://example.org/trackback-url" />

も使えるようになってます。
IDもAtomチックな表現になってます。

現在議論中の案は、
*TrackBack送信結果の取得を標準のHTTPのステータスコードを使うなど、Atomを参考によりREST風にというかよりシンプルに、とか、
*送信元を見に行って言及リンクがあるか判定する
*TrackBack仕様のバージョンを指定出来るように
などがあるみたいです。

現在のドラフトやIssuesListを見ても特に具体的な認証方法とかについてはまだ言及がありません。大雑把に「HTTPの認証を活用する」といった程度で、後は「モデレーション」とか「IPアドレスでBlackList」とかの対応についての言及があります。でもHTTPの例えばBasic認証かけても、TrackBackの送信先毎にユーザ名パスワードなんて覚えてられないのであまり現実的ではないなぁと。

OpenIDとかTypeKeyが活用できるようになると良いと思って、出来るだけ標準化には参画していきたいと思います(と言いつつ、Atomワーキンググループの方も時間的に今は追っかけるだけで精一杯ですが^^;)。

個人的には、送信者のTypeKey等のOpenなIDが必須で、IDがBlackListに登録されていない言及ありTrackBackのみ受け付ける、とかの指定がしたいなぁ。それかキューに溜め込んでのモデレーションとOpenIDやTypeKey等のIDによるBlackList管理がベストかなと思います。IPアドレスのBlackList管理はあまり効果的ではないと思います。ダイアルアップなんか特にそうだけどIPアドレスはコロコロ変わるので意味ないですし、無実の人も弾くことになるのが落ちのような気がします。

でも、TypeKeyをTrackBackの送信に使えるようにするには、ここで書いたような事なども解決し無ければならないのかもしれませんね。一筋縄ではいかなそうだ...。

投稿者 BlogWrite担当 : 17:39 | コメント (0) | トラックバック