ただのにっき
2009-07-06(月) [長年日記]
■ Amazon API認証のPROXYを書いたよ(2)
amazon-auth-proxyの仕様
(2009-07-07:URL形式の仕様追加。レスポンスについて仕様追加。)
(2009-07-23:レスポンスとして302リダイレクトを強く推奨。)
(2009-07-29:Styleパラメタ対応について追記。)
先月公開したamazon-auth-proxyだが、実は満足に動いてなかった(笑)。というか、単純なPROXYになればいいと考えていたけど、ちょっと複雑な事情があったので、仕様をもう少し確定する必要があった。コードは引き続きGitHubから:
とりあえずこれで、手元の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超カッコワルイ。