HepCat Dev and Test: REST アーカイブ

2007年12月10日

AtomPub クライアントのベータ公開

次世代Web標準プロトコルなる、Atom Publishing Protocol (AtomPub) の、（汎用・テスト用・開発用）Clientソフトを公開しました。というか、なんとか公開にこぎつけました。

基本的には、こちらの英語版のページで更新情報を発信していく予定です。AtomPubを利用したウェブサービスの開発の助けになれば幸いです。

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

2007年09月08日

久しぶりにAtomの話題 - WordPressが第一号か

AtomPub（aka 「Atom出版プロトコル」）はほぼ完成した訳ですが、まだなかなか正式な実装が無い状態が続いていました(Google のGDataはちょっと別として)。しかし、今月下旬公開予定のWordPress 2.3でついに、AtomPub正式対応を果たすようです。

WordPress 2.3 beta 1 has significantly upgraded support for the Atom Publishing Protocol. - WordPress 2.3 ♥ AtomPub

Anyhow, WordPress 2.3 is going to be a first-rate Atom Protocol sever. - Long-Weekend Fun

実は、Atomプロトコル用のライブラリを秘かに開発していて（元はここで公開していたもの）、これを使ってそろそろ色々とソフトウェアを公開して行きたいなぁと思っています。

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

2006年08月24日

GData API for Google Base

という事で、期待していた通り、Google Base APIが公開されたようです。

New GData API: Google Base
http://code.google.com/apis/base/

ただ、やっぱりGoogle Base自体がまだ内容的に欧米セントリックという所があるので、（というかGoogle Base自体日本語化されていない？）ちょっと残念ですが、このAPI公開は多方面で非常に意味があるなぁと思います。検索エンジン業界にとってもその他の分野でもこの意味は長い目で大きな影響がある気がします。

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

2006年08月17日

RESTにおけるベストプラクティス：エラーハンドリング

RESTfullなAPIにおいてのエラーハンドリングについては重要なのですが、今まで（特に日本では知っている限り）あまり言及されたことがなさそうなのと、オライリー系のサイトでたまたま今日良い記事 RESTful Error Handling を見つけたので、ココで紹介したいと思います。（2003年12月の記事ですが何故か見落としていました）

この記事では、REPSfullなWebアプリケーションにおいて、エラーが発生した時の動作は（調査した所）一般的にいって４っつの方法が利用されているとしています。

１．HTTPステータスコードのみ

例えば、

http://www.example.com/xml/book?id=1234&dev_token=ABCD1234

のようなアドレスでGETした時、もし"id="によって指定されたデータが見つからなかった場合、HTTPステータスコードの404 Not Found を返す、といった具合。

２．空のレコードセットを返す

例えば、Atomフィードを返すようなケースで、エントリが一つもないフィード空フィードを返す。この場合、そもそも不正なIDなのか、単にまだ存在しないのかなどは分からない。

３．HTTPヘッダーを拡張する

HTTP/1.1 200 OK
...省略...
X-DAS-Status: 403
Content-Type: text/plain
Content-Length: 10
Date: Sun, 30 Nov 2003 21:02:13 GMT

上記のように、HTTPヘッダー内にアプリケーション固有のエラーコードを埋め込む。（注：確か偉い人がX-＊＊のような拡張は安易に行なうべきではない、といった事を言っていました）

４．XML文書を返却する

<?xml version="1.0" ?>
<xoomleError>
　　<method>doGoogleSearch</method>
　　<errorString>Invalid Google API key supplied</errorString>
　　<arguments>
  　　　<hl>en</hl>
  　　　<ie>ISO-8859-1</ie>
  　　　<key></key>
  　　　<q>oreilly php</q>
　　</arguments>
</xoomleError>

のようなXML文書を返却して、エラーの詳細を通知する。

RESTにおけるベストプラクティス

ではRESTベースのWebサービスではどの方法がベストプラクティスと言えるのでしょうか、と筆者は問いかけ、未だベストプラクティスといえるものは無いようだと述べています。

しかし、もっとも重要なのは、「人間が読めるエラーの説明文」、「アプリケーション固有のエラー」、「機械処理できるエラーコード」であり、この三つのカテゴリを含む、少なくとも下記の条件を満たすのが大事なんじゃないかと述べています。

HTTPステータスコードはHTTP通信に限ったエラーのために用い、アプリケーション固有のエラーには用いない。
エラー発生時には、必ず詳細を含んだXML文書を返却する。
XML文書にエラーコードと共に人間が読めるエラーメッセージを含めよ。具体的には下記の例：

<?xml version="1.0" encoding="UTF-8" ?>
<error>
<error_code>1001</error_code>
<error_msg>不正な Google API キーです。</error_msg>
</error>

これを実践することによって、Webサービスは利用側の苦労は軽減し、問題が起きた時の対処も楽になる。エラーコードを元に適切な挙動をする事も出来る。

記事は大体上記の感じです。最後のまとめ部分は、１００％同意する所です。以前、関連する事を、REST原理主義という微妙な記事で書いてしまいましたが、元々はAtom Publishing Protocolのワーキンググループ内での議論がきっかけでした。

個人的にAtom Publishing Protocolでエラーハンドリングのことが何も決まっていないのは問題だと思い、エラーフォーマットを提案していたのですが、大体において反応は、あると便利（４．XML文書を返却する）というのが多数、あるべきというのは少し、無いべき（１．HTTPステータスコードのみ）というのが少数だが激しく、という感じで結局、仕様には含めない、という事になっています。（このワーキンググループでは、異論があるのは本仕様外とする、という傾向が常々指摘されているw）

つまり、

「人間が読めるエラーの説明文」：　なし（追記：正確にはリスポンスのボディに何かが返される場合がある。何かは極端な話×印の画像かもしれない。文字列だとしても、JSONかもしれないし、XMLかもしれないし、ただのテキストかもしれないし、Base64エンコードされているかもしれない。さらには文字コードの判定と変換といったWebブラウザ並の処理の手間がかかる。もしこれが特定のXMLフォーマットが返ると決まっていれば、これらの問題と手間はすべて解消される）

「アプリケーション固有のエラー」:：　なし（追記：正確にはHTTPステータスコードで間に合わせる）

「機械処理できるエラーコード」：　HTTPステータスコードで間に合わせる

という残念ながらベストプラクティスとはかけ離れたものとなってしまっています。最終的な希望は、Atomのコア仕様に含まれなくても、拡張仕様として後付けできるという事で、今後の試行錯誤で何らかのフォーマットが出来て、それにまとまっていくことが考えられます、というか強く希望しています。

なお、ホンモノのRESTベストプラクティスを読みたい方は、こちらのスライドをどぞ。

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

Blogger + GDataとoptimistic concurrencyなど

Bloggerのブログがアップデートを控えてベータ版が公開されています。主な変更は、

GMailでメールにラベルをつけるのと同じように、記事にラベルをつけられる。（カテゴリの感覚）
記事を誰が読めるか指定出来る（Voxと同じ方向性）
マウスのドラッグ＆ドロップでレイアウトを変更

など。ここで新機能の紹介と、日本語のニュース記事は、ここや、ここ。今後徐々にベータ版に移行できるようにしているそうです（現在移行できるブログに制限がある）。

感覚的には、日本ではあまりBloggerは利用されていない感じがして身近にインパクトはありません。ただし、GoogleのGDataAPIに関する動きの一環として、今回のベータ版からGDataAPIを利用した投稿が出来るようになったのが興味あります。

GDataAPIと言えば、新しいAtom Publishing Protocolベースの規格で、今の所、Googleカレンダーそして今回のBloggerで使えるようになりました。（Google Baseで使えるようになるのが待ち遠しい..）

Bloggerでの利用方法と詳細は、Using the Blogger Data API。

個人的な感想としては、Atom Publishing ProtocolベースのGDataAPIといっても、一癖ある感じです。特に、AtomicとIBM系のAtomサーバー実装などで行なったテストなどと比べると幾つか面倒な点がありました。

一つは、GDataAPIの独自のクセのある認証方法、もう一つはoptimistic concurrency (OCC)。　Googleを皮切りに、IBM系のシステムでもこのOCCを検討しているらしい...。と同時に、一部で議論になりつつもあるのがOCC。

意図しない上書きなどによる、データの誤った喪失を防ぐにはOCCは安易な方法だけれども、万が一、かち合った（conflict）場合の処理方法（DiffとMerge）、を考えると現実的ではないし、第一ぜんぜん楽しくない。例えば、バージョン管理システムのSVNでConflictがあると、「エーイ面倒くせーい、一旦全部削除してしまえ」という事がたまにあるのだけど（ほんの稀にですw）、それと似た感じ...

最悪なのは、記事を編集して投稿したら、Conflictが起きたので、今のは破棄するか、最新の記事を取得し直して一から書き直してください、見たいな事が起きてしまう事ですよね...。

他の方法としてはClient-ServerデータベースアプリケーションでよくあるLock。これだと、某ユーザーがアクセス中なので変更出来ません状態に陥ってしまいます。なので、多くの場合、後勝ちの方法で、最後に更新されたデータで上書きされる、というのが現実的に採用されています。多分現在のブログは、この後勝ち。どれもそれぞれ欠点というか問題があります。

カレンダーアプリケーションのようなケースでは良いですが、その他のケースでは個人的には、安易に特定の仕組みを導入するよりかは、実装と運用方法でカバーするのがベストのような気がしますが、もうちょっとこの件追っかけて行きたいと思います...。

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

2006年06月30日

TypePadでは、存在しないファイルもHTTP Status 200を返す！？

6月22日付けの、TypePadのバージョンアップで、BlogWriteからの画像等のファイルの上書き確認が上手く行かないとの報告をサポートフォーラムで頂いたので、調査していたのですが...

TypePadの新機能
ウェブページ上に破損画像（参照先（src）にファイルが存在しない画像タグ（img））がある場合、従来はブラウザの設定に準じた表示となっていましたが、1.8から破損画像があった場合は「Image not available」という画像を表示するように仕様変更しています。

アカウントをもっていないのでBlogWriteでの確認は出来ていないのですが、上記の記述とヘッダーを見る限り、存在しないファイルに対して、別ファイルを返すようで、つまり302で飛ばして、結果別ファイルをHTTP Status Codeの 200で返すように変更したようです。

うーむ、存在しないファイルはHTTPヘッダーに404 Not Foundで返すべきなんじゃなかったでしたっけ？

GIFファイルをアップロードしようとしていて、HEADしたら、
HTTP/1.0 200 OK
Content-Type: image/gif
が返ってきたら、そのファイルは存在する、と判断する他ないでしょう。

ということは、現実世界では結局、一つ前に書いたように、HTTPのステータスコードなんてまったくもってあてになりません。このサイトを運用しているレンタルサーバーでもページが存在しないとデフォルトで「見つかりません」ページが200で返ってくるので時々問題にはまります。（ま、.htaccessで設定を上書きするなど方法はありますが）

BlogWriteでは画像ファイルを投稿する時、既存のファイルを誤って上書きしてしまわないように、事前に存在するかどうかHEADリクエストで確認しています。（デジカメ写真とかだと同じファイル名になりがちで、複数人で投稿するブログだと、意図しないで上書きしてしまう事があるため、BlogWriteでは上書き確認機能として持っています。個人的にはBlogWriteの優れた点の一つだと思っています）

TypePad側としてはユーザーの利便性を考えてのことだと思いますし、その姿勢は分かるのですが...。 HTTPの仕様違反というか、その副作用は理解されているのか、気になります。

Update：　検討した結果、上書き確認の機能を設定で、ブログごとにオン・オフできるようにする方向で対処したいと思います。

参考ー＞　Web屋のネタ帳：　ステータス200なのに「その商品はありません」

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

2006年06月16日

REST原理主義

ってのがあると思うのです。つぶやきモードです...。

RESTってのは既存のWebアーキテクチャを有効利用するというもので、SOAPやWS-*と比べてすごくシンプルな解決策で素晴らしいと思うのだけど、例えばAtomPPでも最近顕著に見られるような気がしてならないのは、既存のWebアーキテクチャ絶対主義というかなんというか...それ以外の解決策は認めない、という雰囲気。

しかし、既存のWebアーキテクチャが完全かというとそうでもなく、問題はいろいろ存在しているのではないかと思うわけです。例えば...

HTTPステータスコードは信頼できない。
ファイルが見つからないときには４０４ではなく「見つかりません」ページが２００で返ってくるとか、５００インターナルサーバーエラーだけじゃユーザには何が起きたか分からない、というか独自のエラー文を返したい時はどうするのかなど、もろもろ。

MIMEタイプは意図した通りに動かず、誤用され無視される。
IEなどはファイルの中身を解析して判断してるし。charsetの指定も嘘が多い（apacheのデフォルトcharsetのままとか）。さらに言えば、セキュリティホールを突く攻撃にも利用される。

ここら辺、色々苦労があってノウハウが溜まってなんとかやってきた所があるわけで、決して銀の弾丸だとは言えないはずです。

にも関らず、例えば、プロトコルの通信時にエラーが起きたら、「HTTPステータスコードを返すだけで良いのだ」というのは原理主義的だと思う。ボディに含まれるのは、バイナリのJpeg画像かもしれないし、XMLかもしれないし、HTMLかもしれない。それがHTTPでありWebだ、と言われればそうだけれど、それでは何の解決にもならないと思います。

なんか、現状ある問題点の解決をするのではなく、単にWebアーキテクチャを再定義して原点に無理やり引き戻したいだけなんじゃないかと。

上記のケースであれば、上手くハンドリングして表示できるクライアントは、Webブラウザのみという事になってしまいます。で、現状WebブラウザはPUT、DELETEしないからまともなRESTクライアントアプリは存在しない、という事になってしまう...。

Webアーキテクチャにこだわるのは良いけれど、自分で自分の首を絞めるようなことにならなければ、と願って止みません。

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

2006年04月20日

Atomベースの Google Calendar Data API公開

Google Calendarが先日公開されて大変便利に使っているわけですが、このカレンダー情報を外部アプリケーションから更新するプロトコルが公開されました(はてブ経由ogawaさん経由)。

Google Data APIs Protocol （GData）というのが、今後Googleで汎用的に使われるベースとなるプロトコル。そして、このGoogle Data APIを利用した、Google Calendar 向けの仕様が、 Using the Google Calendar Data API という事らしいです。

iCalベースとかだろう、とたかを括っていたら、中身を見てビックリ、The Atom Publishing Protocol＋OpenSearch。それに、現時点ではまだ The Atom Publishing Protocolで規定されていないCategoryや、APPとは別仕様で採用する予定だった全文検索や更新されたエントリーのクエリー方法まであります。

The Atom Publishing Protocol ベースなので、当然RESTです。

興味深かったのが、Account Authentication for Installed Applications という、インストールするアプリケーション用の認証方法も公開されていることです。「TypeKeyとWeb APIの（ちょっとした）落とし穴」で書いたデスクトップ上のアプリケーションからの認証もしっかりと考慮してくれている所がステキです。Proxy Authentication for Web Applications っていうWebアプリケーション向けの外部認証システムは未だ未公開だけど別途用意するようです。

今後、GoogleはGoogle Calendarのみならず、Bloggerやその他のサービスでも、（旧AtomAPIでなく）この The Atom Publishing Protocol ベースの利用をガンガンおしていくんではないかと思います。

The Atom Publishing Protocol (現在ドラフト08版) 対応の相互運用性テストクライアントを、ここで公開していますがそのままではGoogle Calendarで使えないっぽい（認証とかIntrospectionとか）ですが、これ用に作ったDelphiのAtomライブラリを利用すれば、簡単にCalendarクライアントが書けそうです。

因みにGoogle謹製のJavaとC#ライブラリも公開されてます。でもHTTP＋XMLなんでどんな言語でもOKです。早速PerlライブラリがCPANにアップされる予感します。

追記：
Atom 1.0に対応したPerlライブラリとしては、XML-Atom-Syndication なんかがあります。でもプロトコルの方はまだ仕様が固まっていないのでまだプロトコル向けのPerlライブラリは無いようです。因みに、The Atom Publishing Protocol draft-08に対応したサーバーとクライアントの一覧は、先日Wikiページ AtomPubTesting に作成されてますので、ご興味のある方は是非。

で、想定される用途としては、CRM（顧客関係管理）ソフトウェアやプロジェクト管理（BaseCampのAPIと連携して）から、打ち合わせ日時や〆切りを入力したら同時にGoogle CalendarにもEventを登録して...などなど色々とやって見たくなります...。あ携帯用クライアントとかも需要がありそうですね。

追記：そういえば、先日勢いでThe Atom Publishing Protocol に関するGoogleグループ (Atom Protocol -ja) 作りました。毎度ですが、勢いです。

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

2006年03月06日

RESTなWebAPIの開発支援ツール

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

ちょっと前になりますが、RESTのAPIを開発する上で便利かもしれない社内製ツールを公開しました。５年ぐらい前に学習目的で作った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自体の事を詳しく書いてこなかったのですが、実は２００３年頃から一歩引いた所から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のような冗長で無駄の多い仕様を同時に実装して見ると、違いが実感出来ます。

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

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

Trackback標準化の件

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

１日の内にこんなにまとめて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) | トラックバック

2006年02月24日

TypeKeyとWeb APIの（ちょっとした）落とし穴

MTブログでお馴染みの、SixApart規格に、TypeKeyという技術的にも興味深いオンライン認証の仕組みがあります。

これ自体は良いもので、近日一般公開予定の（業務系ソフトですが）Webアプリケーションで使ってみようかなーとちょっと頭をかすめたので、実装を考えてみました。

ユーザとしての利点は、色々なところのID＆パスワードを管理する必要なくなる、とか、パスワードを知らせずに様々なサービスで同一のIdentityを利用できるとか...。Webアプリケーション側には、認証情報を保持しないでも良い、というちょっとした利点があります。

TypeKeyの動作として基本的には、

認証画面がWebベースなので、TypeKeyのサイト
https://www.typekey.com/t/typekey/login
へ飛ばして、ログインしてもらって、

認証結果OKだったら、ユーザーのID名と本物か確認するための情報などが_returnで指定したURLにパラメータとしてくっ付いて、リダイレクトされて返ってくる...。

というものだと理解しました。

以上までは良くて、お？いっそ自前の認証捨ててTypeKeyオンリーにしちゃおうか...とまでいったのですが、これにはちょっと問題ありげな事を発見。今開発しているのはいまどきのWebアプリ（w）なので、近い将来的にWebAPIを実装し、クライアントソフトとの連携を考えている訳です。となると、デスクトップ上のクライアントソフトからも認証システムが利用出来ないといけません。今のTypeKeyの仕様だと、用意されたWebページで認証、結果は指定のWebページへ、とデスクトップをすっ飛ばしてくれます。

で、TypeKeyのREST版を希望したいなーと。HTTPのGETでID＆Passのパラメータ付でTypeKeyに接続して、JSONでもXMLでも何でも良いけれど認証結果を返してくれたらOKですから。 Spammer対策には、各クライアントソフトにAppKeyを発行し、疑わしいのはBlackList行き、とか。

もっとも、PC上のクライアントソフト内でIDとパスワードを入力してもらって、それをTypeKeyサーバーに送信している時点で、「サードパーティが生の ID/PW を知ることなく」という第三者の認証システムを利用する利点の一つが損なわれる可能性も無きにしもあらず...というのが難です。しかし、まるっきりサードパーティのWebサイトに自分の素のID＆Passを渡すのと自分のPC環境内のソフトに入力するのはまったく別の次元なので、一緒くたに話すべきではないでしょう。

こう考えると、現状での方法は、PC上のクライアントソフトからや自Webアプリケーションへのログインは自前のID＆Passで認証、それ以外のサードパーティのWebサイトでの利用には、TypeKeyみたいな認証とかを使ってもらうという事になるのでしょうか。なんか違うなぁ...。出来ればTypeKeyオンリーでやれたら楽なのに...ってそれもちょっと違うか。

~~新たな認証システムのプロトコルを検討されている場合（~~＊１）（＊２~~）、このあたりの対応も上手い具合にならないか検討してもらえると嬉しいですが、どうでしょか。~~ 　

追記：よくよく考えた結論。
１．TypeKeyなどだけに認証を依存したWebアプリケーションは場合によっては~~イクナイ~~難があるかも。
２．デスクトップのクライアントは“サードパーティ”扱いではない、という方向でここはひとつ。

投稿者 BlogWrite担当 : 21:29 | コメント (2) | トラックバック

2005年11月25日

XML開発者の日へ

行って来ました。今日というかもう昨日...。久しぶりに刺激的な日でとても素晴らしかったです。皆さまありがとうございました。パネルであまり大したことはしゃべってなかったような気がしますが、キニシナイ..。

色々と意見交換できて最高でした。

早速Wikiを作成されていらっしゃる方が...。

追記：物凄い勢いでメール、サポートフォーラム書きコが溜まっていましたが、本日メールお返事力尽きてできなかったので申し訳ありません。

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

2005年10月18日

第八回XML開発者の日

というのが11月24日、開催されます。

RESTとAtom Publishing Protocol（AtomAPI、AtomPP、APP）を中心に、Web2．0時代を支えるRESTによるAPIや来年注目の技術トレンド話題のAtomAPIについてのイベントなのですが．．．。

えと、私もパネルでチョビット何か話す機会を頂きました。

なんか、はてなのNaoyaさん（アルファブロガー）とか、SixApartのhirataさん（日本のブログ界の立役者）とか、XMLの父とも言える村田さんとか、REST入門を書かれた yohei さん、RESTWiki を作った方、かの高橋メソッドの高橋さん．．．

そうそうたるメンバーです。

浮きそうです、というか浮いてます。

というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^;　

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

2005年09月16日

2005年07月13日

AtomAPIとCollection

Atomフォーマットは、完成まで一週間を切ったとかいう感じですが、AtomAPI（正確には、The Atom Publishing Protocolで、日本ではAtomPPとも、海外では「APP」とも略される）の最新動向はというと、完成まで、雑感ではおそらく今年いっぱいかかると思われます。

現状のEditURIとかPostURIとかCategoryURI、UploadURI、ResourceURIとかはばっさり捨てられています。基本的な流れは変わっていませんが、用語とか、フォーマット、拡張性が根本から変更されたと言っても構わないでしょう。

続き

AtomAPIに新規に導入された機能・概念

workspaces
Workspaceというのが、例えばブログだったり、Wikiだったりしますが、ブログのみに用いられるわけではないので、特に似たようなのであれば何でも構いません。

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://purl.org/atom/app#">
     <workspace title="My Blog" > 
        <collection contents="entries" title="Blog Entries" 
            href="http://example/atom/myblog/entries" />
        <collection contents="generic" title="File Uploads" 
            href="http://example/atom/myblog/generic" />
     </workspace>
</service>

collections
Workspaceに含まれるのがCollectionです。Collectionとは、具体的にはブログで言うところの、エントリー（記事）、カテゴリー、ファイル、画像、動画、リンク、雛形、等々の一覧です。

Collectionに関連付けられたURIにGETすると、その一覧、つまりCollectionを取得できます。

<?xml version="1.0" encoding='utf-8'?>
<collection xmlns="http://purl.org/atom/app#">
   <member title="ほげ？フガフガ"
         href="http://example.com/atom/myblog/entry/7700a0" 
         updated="2005-07-16T23:09:03-0500" />
   <member title="フガフグ"
         href="http://example.com/atom/myblog/entry/7700c9" 
         updated="2005-07-15T23:06:09-0550" />
</collection>

memberが個々のアイテムといって良いでしょう。このCollectionのURIにPOSTするとmemberの新規追加で、以前（PostURI相当）と同様の挙動ですね。memberに関連付けられたURI（EditURI相当）にGETすれば、アイテムがEntryドキュメントとして返ってきます。PUTすると更新、DELETEすると削除。

リソースのアップロードで異なるのは、現状ではEntryドキュメントにBase64で埋め込んでいましたが、バイナリーChunkをそのままアップロードします。
   POST /collection HTTP/1.1
   Host: example.com
   Accept: application/atomcoll+xml
   Content-Type: image/png
   Content-Length: nnnn
   Name: hoge.png

...binary data...

Rangeヘッダー
member（ブログでいう記事）の取得において、範囲を指定する方法が既定されました。これは、HTTP1.1のRangeヘッダーを利用して日付で指定できます。

ここらあたりまで決まったのが、draft-ietf-atompub-protocol-04.txtです。

現状の問題点として、collectionの種類が、「entries」と「generic」しかないため、collectionが複数あった場合、BlogWriteのようなクライアントソフトは記事や画像その他の投稿先をどのように判断するのか...という点があります。というのも、もし画像とカテゴリのCollectionがgenericとして二つあった場合、ソフトウェア的にどっちがどっちだと判断できないからです。かといってカチッと決めてしまうと汎用性を損なう恐れがありますから、議論の余地があります。

その、Collectionsの識別を議論しているのが、MLの「Which collections to upload and post to」から始まるスレッドです。これがはっきりするまで、実装するのはまだ早いかとな思います。

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

2005年04月07日

はてなブックマーク AtomAPI

が出たそうです。
「はてなブックマークAtomAPI」

用途としては、FireFoxのExtentionでツールバーから１Clickではてなブックマークに追加したり、ブログのサイドバーに「最近のブックマーク」みたいにして埋め込んだり、ローカルのお気に入りとはてなブックマークとの同期を取ったり...と妄想が広がります。

さて、このオープンなAPIを利用したどんなアプリケーションが出てくるのでしょうか。

個人的には、MTのIndex再構築時に「最近のブックマーク」をサイドバーに挿入させたいので、誰かPlugin作ってください。M(_'_)M

あ、はてなダイアリーのAtomAPIも期待しております。

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

2005年03月12日

Blogger AtomAPI　認証方式がWSSEからBasic Authへ

BloggerのAtomAPIの認証方法に変更があったようなので、BlogWriteからBlogger.comのブログにログイン出来ない場合があります。
Authorization: Status on SSL/Auth Basic?

認証方法が、WSSEからBasic Authになったようです。が...SSL通信はまだのようなので、ほにゃにゃらエンコード（笑）したユーザー名とパスが普通のHTTPで送信されてしまいます。まったくの平文のXML-RPCよりはマシというぐらいです。Blogger.comの意図がちょっと見えません...。

という事で、
BlogWriteアップデートVer.1.4.0です。

追記：
SSL通信が有効になったそうです。
エンドポイントも、
https://www.blogger.com/atom
に変更出来ます。
一、二週間したら、すべての
http://www.blogger.com/atom
へのリクエストは、https://...のSSLの方にリダイレクトされるそうです。

追追記：
Bloggerから「Blogger AtomAPI Documentation」公開
http://code.blogspot.com/archives/atom-docs.html

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

2005年03月03日

解説:Atom

技術評論社の編集者の方より寛大なる許可を得て、技術評論社「Software Design」2005年1月号第2特集「次世代Webテクノロジ：Atom基礎講座」オンライン版を公開したいと思います。

解説:Atom - Atomとは何か: RSSやXML-RPCとの比較、そしてAtomAPIの使い方まで

どぞ。

#草稿を元にXHTMLを生成したので、タイポやバグってる所があるかと思います。おいおい修正いたします。なお、執筆は2004年の10月頃のため、一部情報が古くなっている個所がありますがご容赦ください。これもおいおい余力が出たら更新いたします。
もし、記事に間違い、勘違い、誤解ありましたらぜひツッコミ頂きたく思います。m(_'_)m

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

2005年03月01日

The Yahoo! Search Web Services - Yahoo! API

Miyagawaさんのブログ経由：Yahoo ready to open up their APIs

「The Yahoo! Search Web Services」
と題してYahoo！のコンテンツやサービスに外部アプリケーションからアクセスし操作するYahoo! APIが公開されました。XML Webサービスそれも、AtomAPIやAmazonと同じく

REST

素晴らしい。

詳細は調査中...色々面白いことが出来そう...。GoogleとAmazonだけでなくYahoo!も目が離せなくなってきました。（Yahoo!Japanはとっくに見捨てていますが...）

追記：こっちにもTB攻撃

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

Link

Download

Documents

カテゴリー別一覧

最近のエントリー

検索

更新情報の配信

HepCat Dev and Test

Blogクライアント『BlogWrite』の開発＆テスト＆アップデート情報をメインに、ブログやWebにまつわる技術的トレンドなどを扱う開発ブログです。