岩本隆史の日記帳（アーカイブ）

はてなダイアリーのサービス終了をうけて移行したものです。更新はしません。

Product Advertising APIの利用ガイドライン変更に対応した

Amazon リリースチェッカー

ガイドラインの変更点

AmazonのProduct Advertising APIの利用ガイドラインが変わりました。利用者にはお知らせメールが来ていると思います。僕には来ました。

変更点は下記の通りです。正確な内容はガイドラインをご参照ください。

  • 1時間に2000リクエストを上限とする（もっとリクエストしたければアソシエイトで売りまくれ）
  • リンクバックURLは組み立てるな。APIから返されたものをそのまま使え
  • APIアカウントとアソシエイトアカウントの登録メールアドレスを統一しろ
  • 一部のオペレーションやレスポンスグループは2010-10-15で廃止する
  • Multiple Operation RequestsやTextStream Search Parameterも2010-10-15で廃止する

リリースチェッカーの対応

僕が運営しているリリースチェッカーでもAPIを思いっきり利用しています。気が早いですが、ガイドラインに従うべく対応してみました。対応順に記します。

1. メールアドレスの統一

APIアカウントとアソシエイトアカウントの登録メールアドレスが別のものだったので、統一させました。ガイドラインからリンクされているページで変更できます。

2. RSSキャッシュ期間の変更

リリースチェッカーの生成する各RSSのキャッシュ期間を、30分から12時間に伸ばしました。リクエスト回数を減らすための措置です。リアルタイム性は求められないアプリケーションなので、一気に半日まで伸ばしました。様子を見て、もっと伸ばすかもしれません。

3. スリープ処理の変更

各リクエスト間のスリープを1.2秒から1.8秒に伸ばしました。3600秒÷2000回＝1.8秒です。月に72,000円ぐらい売上があればもっと呼び出せるんですが、まず無理なので、2000回で計算しました。

ちなみに1.2秒にしていたのは、もともと「毎秒1コールを超えない」という規約があり、それに従っていたためです。開発当時、スリープをきっかり1秒にしていたら、エラーレスポンスが返るケースが頻発したため、1.2秒にした記憶があります。

4. 商品URLの変更

これまでは「http://www.amazon.co.jp/exec/obidos/ASIN/{ASIN}/{アソシエイトタグ}/ref=nosim」というURLを自前で組み立てていたんですが、APIのレスポンスに含まれるURLをそのまま使えとのことなので、そうしました。

リリースチェッカーをお使いの方は、がんがんRSSが更新されて驚かれているかもしれませんが、そういう事情です。すみません。

気になるのは、APIのレスポンスに含まれるURLがずっと固定なのかどうかです。これが流動的だと、URLが変わるたびにRSSが更新されてしまいます。もしそうであれば、リリースチェッカーの役目もそろそろ終わりなのかもしれません。

5. APIバージョンの変更

ガイドラインからリンクされているベストプラクティス・ガイドに「Use the Latest API Version」とあったので、リクエスト時のバージョンパラメータを「2009-11-01」に変更しました。

6. Multiple Operation Requestsの継続依頼

リリースチェッカーはMultiple Operation Requestsを活用しています。名前の通り、1回のリクエストで2つの処理をお願いできる便利な方式です。

これがなくなるとリクエスト回数が倍増するため、リリースチェッカーのパフォーマンスがかなり落ちるはずです。

「これらのAPIへのアクセスを引き続き必要とされるお客様は、お客様の事例を確認・検討させていただきますので、こちらまでご連絡下さい」とあったので、メールフォームで継続のお願いを送信しました。

所感

ガイドラインには「一部の開発者様が、非常に大量の商品データを要求しながら、非常に少ない商品の売上額しか発生させていないことが判明しています」と記載されています。これが今回の変更のきっかけということです。

「非常に大量の商品データを要求」するような開発者のなかには、規約（毎秒1コール）を気にせず富豪的にリクエストしていた人もいるのではないでしょうか。いろいろなアプリケーションで問題が起きそうな予感がします。僕の杞憂ならよいですが。

追記（2010-07-16）

APIのレスポンスに含まれるURLが長すぎて、RSSリーダーによってはうまく扱えないことが分かりました。bit.lyによるURL短縮を検討します。だんだんごつくなっていくなあ。

追記その2（2010-07-18）

bit.lyによるURL短縮処理を入れました。bit.lyにも呼び出し回数上限があるので、短縮URLが取得できなかった場合は長いままのURLを返すようにしています。

そういう次第で、またフィードががんがん更新されることになります。ユーザのみなさまは驚かれることと思いますが、あいすみません。

追記その3（2010-07-19）

ある程度は予想していたのですが、bit.lyのAPI呼び出し回数上限をあっさり超えてしまったため、URL独自組み立て方式に戻しました。なお、組み立てるURLは、「AmazonのアソシエイトID入りで一番短いURL | Creazy!」を参考に、「http://www.amazon.co.jp/o/ASIN/{ASIN}/{アソシエイトタグ}」のようにしています。

独自組み立て方式を採用すると、Product Advertising APIのガイドラインに反してしまうことになります。そのデメリットは、いくら稼いでも2000回以上のリクエストが望めなくなるというものです（ガイドラインからリンクされている「よくあるご質問」を読んでの理解）。リリースチェッカーの場合、もともと2000回に収まるようプログラミングしているので、デメリットはまったくないことになります。

無駄な手間をかけてしまった感じですが、bit.lyの使い方が分かったので、よい勉強になりました。ユーザの方に迷惑をかけてしまったのは反省点です。

追記その4（2010-07-22）

「http://developer.amazonwebservices.com/connect/message.jspa?messageID=187443#187443」を読んで知ったのですが、Multiple Operation RequestsとBatch Requestsは別物なんですね。同じ種類のリクエストをまとめたのがBatch Requests、違う種類のがMultiple Operation Requests。

リリースチェッカーで使っているのはBatch Requestsのほうでした。こちらが存続するのであれば、問題なしです。