Rakuten Rapid API
前にTwitterを制御するためにTwitter APIを、またコロナウイルスのデータを取得するためにOpen Data Portalを使ってみました。
こうやって使ってみるとAPIってなかなか便利だなと思うのですが、まだまだ経験が足りません。
特にデータを取得するのは便利なのですが、Open Data Portalではアクセスが出来なさすぎて経験値を得ることがそれほどできませんでした。
ということで、他に何かいいAPIがないかなぁ、そして何かいい使い道は何かいいのがないかなぁと考えていたのですが、現在の天気をAPIで取得して、ツイートするという基本的なことをまずはやってみようという考えに落ち着きました。
そして天気のAPIを探したところ、Rakuten Rapid APIに色々なAPIがまとめてあることを知りました。
ということで、今回はこのRakuten Rapid APIに登録し、天気のAPIを少しいじってみることにしましょう。
Rakuten Rapid APIに登録
ということでまずはRakuten Rapid APIに登録をしましょう。
こちらのウェブサイトにアクセスします。
そして画面右上の「新規登録」をクリックします。
登録画面に移りますが、なんとGithubのアカウントで登録ができるということなので、今回はこれを試してみましょう。
ちなみにGithubへの登録はこちらの記事をご覧ください。
ということで「新規登録：Github」をクリックします。
Githubのログインを促されますので、ユーザーネームかメールアドレス、そしてパスワードを入力し、Githubへサインインします。
連携してもいいかという確認画面が出てきますので、「Authorize RapidAPI」をクリック。
これで登録が完了ですが、Rakuten Rapid APIで使う名前と組織名の入力が促されます。
今回の場合、会社でやっているわけではないので組織は特にないため、組織名はウェブサイト名にしておきました。
また「組織用のアカウントが必要」にチェックを入れることでどうやら複数人で同一のAPI keyが使えるようなるみたいですが（間違っているかも）、今回は個人なのでチェックを外したままにしておきました。
これで新規アカウントの作成が完了し、右上のアイコンがGithubで使っているアイコンに変わりました。
天気のAPIの検索
次に天気のAPIを探していきましょう。
名前が分かっていれば、検索欄で検索するのがいいでしょう。
ただ今回みたいに漠然と「天気のAPI」を探したい場合はカテゴリーから探す方がいいでしょう。
ということで検索欄の下の「すべてのカテゴリー」をクリックします。
色々なカテゴリーがあるので、どんどん下へスクロールしていきましょう。
一番最後に「天気」のカテゴリーが見つかりました。
ということでこの「天気」をクリックします。
天気に関連するAPIの一覧が出てきますが、今回は一番良さそうな「Open Weather Map」を試してみましょう。
ちなみに何が良さそうか判断基準はいろいろあると思いますが、この一覧からパッとみて分かるのがそれぞれのAPIのボックスに書かれている三つの数字です。
左から人気度（10段階 10が一番良い）、過去３０日間の接続するまでの平均時間、過去３０日間の正常稼働時間です。
どこかのAPIのように繋がらないのは困りますし、あまり接続するまでの時間が長すぎても困るので、ここら辺の値を気にしておくのがいいのではないでしょうか。
あとはそれぞれ試してみて、使い勝手のいいものを選ぶのがいいのではないでしょうか。
ということで「Open Weather Map」をクリックして移動したページがこちらです。
左下に使える機能の一覧があります。
今回は現在の天気が欲しいので、「Current Weather Data」をクリックします。
大切なのは自分が使えるかどうかなので、右側のプログラム例でPythonでの使い方を見てみましょう。
コードスニペットの「（Node.js）Unirest」と書かれているところをクリックします。
するとプログラム例が用意されているプログラム言語一覧が出てきますので、下にスクロールしていきます。
「Python」の中に「http.cliant」、「Requests」、「Unirest」とあるので使ったことがある「Requests」を見てみましょう。
ちなみに「Requests」を使ったのはOpen Data Portalをいじった時でした。
また機会があれば解説ページを作ることにしましょう。
するとPythonのRequestsを使ったプログラム例が表示されます。
意外とプログラム量は少ないので、なんとかなりそうです。
真ん中の列にはAPI keyや変更できるパラメータが表示されています。
今回の場合、「q」というパラメータ、天気を取得する位置が必須項目であとはオプションのようです。
料金プランの確認
このAPIを使おうという前に料金プランの確認です。
使ってみたら知らず知らずのうちに高額になっていたなんてことがないように先に確認しておくのがいいでしょう。
上のメニューの「料金プラン」をクリックします。
料金プランのページに移りますので、下へスクロールしていきます。
この「Open Weather Map」にはAPIを利用する回数に対して三つの料金プランがあるようです。
そしてBasicの場合は月に500回のAPI利用で０円ということです。
この月に500回というのは例えば東京の今の天気を取得して1回、大阪の今の天気を取得して1回ということのようです。
ここら辺は次回再度出てきますが、個人で使ったり、試しに使ってみるには500回は十分でしょう（もちろん使い方によりますが）。
もう少し下にスクロールしていくと、プランによって使える機能一覧が出てきます。
とりあえず「Current Weather API」が無料プランに含まれているので、今回は問題ありません。
Basicの「プランを選択」をクリックします。
すると「プランを選択」のボタンが無くなります。
これで登録は完了です。
次にブラウザ上で動作を確認するため「エンドポイントをテストする」をクリックします。
先ほどのAPIの画面に戻りますので、左下のエリアで「Current Weather Data」を選択します。
また今回は例として東京の天気を取得するため、「必須パラメータ」の「q」を「Tokyo, jp」にします。
これで「テスト」をクリックします。
データの取得に成功した際、どんなデータが出てくるかは右下エリアの「返信例」で確認することができます。
今回は実際に動作させたので、その横の「結果」をクリックします。
最初に「200 OK」と書かれていますが、これは送受信が問題なく完了したことを示しています。
そしてその下の「ボディ」の下に書かれているのが、実際の返信内容です。
「ヘッダ」をみるとどのように情報が返ってきたのかをみることができます。
とりあえずプログラムに関してはこのコードスニペットのプログラムを真似ればいけそうです。
残りのAPIコール数
先ほど「Basic」プランでは月に500回APIを利用できるとありましたが、その残りの回数を確認してみましょう。
画面上の「開発者ダッシュボード」をクリックします。
「開発者ボード」というページに移りますので、少し下にスクロールします。
すると「Open Weather Map」と書かれた下に「APIコール 17」と書かれています。
この場合、17回APIを利用し、残りが483回ということになります。
ということで今月は残り483回なので、まだまだ遊べそうですね。
次回はJupyter notebook上でOpen Weather MapのAPIをいじってみましょう。
ではでは今回はこんな感じで。
コメント