ただのにっき

■ eto本届いた

これを次のWikiばな(まだ申し込めます(7/11現在))までに読み込まないといけないのだ。まぁ、まだ時間があるから大丈夫だと思うけど、途中にRubyKaigiとかあるからなぁ。例年、あれが終わった後は腑抜けになるから油断は禁物だ。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
江渡 浩一郎
技術評論社
￥1,650

■ pocketer増刷

RubyKaigiも近づいていることだし、以前作った名刺がそろそろ底を尽きそうだったこともあり、またpocketerで50枚追加した。

今回、写真のバリエーションは変えず。以前使った写真をフォト蔵に残しておけば、ぽんぽん選ぶだけなので楽だ。どうせなら裏面の文字も残しておいてくれればいいのにね。

で、勢い余ってレザーケースまで買ってしまった。このオレンジ色がまたいい感じに好みなんだな。

■ Amazon API認証のPROXYを書いたよ(2)

amazon-auth-proxyの仕様

(2009-07-07:URL形式の仕様追加。レスポンスについて仕様追加。)
(2009-07-23:レスポンスとして302リダイレクトを強く推奨。)
(2009-07-29:Styleパラメタ対応について追記。)

先月公開したamazon-auth-proxyだが、実は満足に動いてなかった(笑)。というか、単純なPROXYになればいいと考えていたけど、ちょっと複雑な事情があったので、仕様をもう少し確定する必要があった。コードは引き続きGitHubから:

amazon-auth-proxy

とりあえずこれで、手元のtDiaryは動いてる。

仕様的には、これくらい決めておけばいいかなー、と:

• 提供するURLは「http://(任意)/(locale)/」とする。(locale)はca、de、fr、jp、uk、usから任意のものを選択できるが、それぞれに対応するAmazon APIを呼び出すこと
• RESTタイプのAPIに対応し、認証抜きの呼び出しを認証付きに変更してする
• パラメタ内にあるAWSAccessKeyIdもしくはSubscriptionIdは、自身のアクセスキーに変更*1
• Timestampはパラメタにあっても無視し、現在時刻で付け直す
• AssociateTagが指定されていない場合は自身のものを付加してよい*2
• Styleパラメタが指定されている場合は、XSLT用のエンドポイント(xml-(locale).amznxslt.com/onca/xml)を使う
• レスポンスは以下のいずれかを選択可能
  • 【強く推奨】認証signature付きのURLを302でリダイレクト(受け取ったクライアントはそのURLを使ってAmazon APIをcall)
  • AmazonのAPIをcallして、その結果を丸々返す

こうやって仕様を決めておかないと、従来のアプリのエントリポイントだけをPROXYのものに置き換えれば余計な変更なしで動くという目標が達成できない。ということで、異なる実装をする人はこのへんに準拠して欲しい。今のところこの方向の実装になりそうなのはこのふたつ?:

• poppen版(on Google App Engine)
• furyu-tei版(on Google App Engine)

逆に、danさんの実装はシンプルでいいかも知れないけど既存のAPI利用者が嬉しくない。

amazon-auth-proxyクラスタに関するアイデア

ところで、open proxyにする場合に、毎秒1回制限とか、不正利用による利用停止の問題が指摘されているが、これは複数のPROXYを束ねて順番に使いまわすことでリスクを低減できると考えている。最初は提案されたDNSラウンドロビンで良いと考えていたけど、参加制約がありすぎるので没。

あとはreverse proxyを用意するか(背後で複数のproxyに振り分け)、302リダイレクトを使うかどっちかかなー。一長一短があるけど後者が楽か。もっとも、Rubyでは$SAFE=1のときにopen-uriが302リダイレクトを処理してくれないという(バグ|仕様)があるので前者じゃないと困るというのがある(笑)。

あと、reverse proxyにするとアクセス元を絞れるので、ダイレクトに不正利用されるのを防げるという利点もあるな。というわけで、誰かreverse proxyを提供してくれないかのぅ。

Web APIに対する私見

あと最後に、これだけは書いておきたい。

デジモノに埋もれる日々のProduct Advertising APIの秘密鍵とクライアント型ソフトに関する公式見解という記事にこんな記述があったけど:

これは本来あるべき姿に戻ったというか、javascriptなどから直接APIを 呼んでいたケースについてはこのように自前のサーバ(CGI等)をクッションとして クライアント直コール型からサーバ型に変換されるべきという意味で 非常にいい仕組みだと思います。

冗談じゃない。こんなクソみたいな仕掛けを考えなきゃいけないなんて、間違ってるとしか言いようがないだろ。

「Amazon APIが無尽蔵に使える共有DB」ではない、という点にはおおいに同意するが、それはあらゆるリソースについて言えることだ。今回の新しい制限によって、APIを嫌がってWebページのスクレイピングに戻る開発者だって出てくるだろう*3。そんな実装のせいでHTMLへのアクセスが1日数百万回になったら、AmazonはAPIと同じようにWebへのアクセスも認証制に移行するか? しないよね。

Web APIは、サーバだろうがクライアントだろうが、HTTPというプロトコルさえ喋れれば誰でもcallできることに意味があるのだ。WebブラウザさえあればどんなWebページも表示できるように、HTTPさえ喋れればどんなAPIにもアクセスできるべきだ*4。真にユビキタスな社会がすぐそこまで来ているこの時代に、Amazonの今回の仕様変更は考えうる最悪のやり方だよ。Amazon超カッコワルイ。