楽天ウェブサービスのデベロッパーIDの扱い

 2月22日に公式のブログにて、「【注意喚起】デベロッパーIDの流出について」というタイトルのエントリがあがっていた。デベロッパーIDはどうやら、他人に使われないように見えないようにしておかないといけないらしい。そこまで厳密なものとは思ってなかった。だって、サンプルとして、JavaScript使用のやつとかが公開されてたしね。
 まあ、だめというのならだめなんだろう。
PHP×WebサービスAPIコネクションズ そういえば、以前、Amazonのウェブサービスも途中で路線変更をしたんだった。というか、去年か。Secret Access Keyというのが新たに設けられたんだったか。
 それまではSubscription IDというものだけだったのだ。そして、公式がやっているフォーラムでは、ユーザーが試したリクエスト(サーバーに送るパラメータ込みのURL)にはSubscription IDを含めてください、試すのが楽だから。というふうに、運営側が、ユーザーにリクエストを出していたものだ。
 ユーザーが何をやったのかを運営側が試すために、わざわざ別途IDを入力しなくてもいいように、ということだったのだが、フォーラムの参加者がそれを実行することはなかったと記憶している。
 まあ、そんなこんなで、楽天のデベロッパーIDは、以前のAmazonでいうSubscription IDと同じ扱いだと思ったのだが、違ったようだ。というのが、ここ最近の感想。
 まあ、楽天としては、「新規デベロッパーID発行の一時停止のお知らせ 」なんてことをしないといけないくらい、サーバーリソースが逼迫してるってことなんだろうけども。
 2chの該当スレッドでは、どっかの情報商材屋が、楽天のAPIを使ったプログラムを大量に売ったので、それの結果が楽天のAウェブサービス用サーバーのキャパオーバーってことになったのでは?という憶測が出ていた。なるほど。さもありなん。
 とりあえず、1秒1回のリクエスト制限を超えないようにいろいろやってはいるけど、それを守っててもサーバー側が対応できないようなのでいろいろ困っている昨今。
 最近はじめたような人が、
 そんなにアクセスを集められる=そんだけリクエストを送る
 っていうことはあんまり考えられない気もするけど、とにかく、楽天にとって想定外なことが起きてるんだろう。
 えーと。がんばってください。楽天の開発者のみなさん。

コメント