「Amazon API Gateway を使って駅すぱあとWebサービス無償版を呼んでみた」 #aws #jawsug #api #駅すぱあとWebサービス
AWS Summit New York にて発表されたサービスのうちの1つである「Amazon API Gateway」を使って「駅すぱあとWebサービス無償版」を試しに呼び出してみた時のメモ書きです
そもそも「Amazon API Gateway」って何よ？って人はひとまず↓あたりを一読
え？「駅すぱあと」ってWebサービスなんてあるの？無料版もあるの？という人は↓あたりを
APIを作ってみる
何はともあれAPIを作らないと始まらないので、以下の画面で [Get Started] ボタンをクリックして先に進みます
すでにAPIが存在する場合は以下のような画面になりますので、[Create API] ボタンをクリックして先に進みます
以下の「New API」画面にて 必須項目である API name を入力して [Create API] ボタンをクリックして先に進みます
API name については日本語が入力可能でそのままAPIとして作成出来ますが、このAPI name で CloudWatch の Backplane に ApiName という項目で登録されます
なので、日本語というか2バイト文字を含んだ名称にするとこれに登録出来ないようで結果としてAPIとしては動作しているが CloudWatch での状態把握が出来ない状態となります
まーあまり2バイト入れる人もいないと思いますが、マネージメントコンソールが日本語化されているのでうっかりあるかも知れませんし・・・
ちなみに、日本語が入っていると↓な感じでエラーで何も表示されませんでした
また、このNew API の画面において既存のAPIがある場合は以下のように Clone from API という項目が追加されて既存のAPIを簡単にコピーすることが出来るようです
Resource を追加してみる
APIの作成が終了すると以下の画面が表示されます
この画面で Resource を追加していくわけですが、左右2ペインの画面で [Create Method] [Create Resource] ボタンは右端でも操作するペインは左側・・・最初本当にどこから Resource を追加すればいいのか分からなかった・・・
ついでに [Create Method] [Create Resource] ボタンと同じ並びに [Delete API] ボタンがまったく同じ色と形で置いてあるのも・・・これも削除するときにどうすればいいのか分かるまで時間がかかった・・・
[Create Resource] ボタンをクリックすると以下の画面が表示されます
Resource Name と Resource Path が必須項目なので入力を行います。今回 Resource Name は station と指定しました。これは呼び出す「駅すぱあとWebサービス無償版」に合わせた形です
Resource Path についてはResource Name を入力すると自動でResource Name と同じものが入ります。もちろん入力して変更することも可能です
[Create Resource] ボタンをクリックして次に進みます
Method を追加してみる
Method を追加したい Resource（今回は station）が選択されていることを確認して [Create Method] ボタンをクリックします
station の下にドロップダウンリストが追加されるので、station に追加したいHTTPメソッドを選択します。
今回は GET を選択しリスト横にあるチェックマークをクリックします
今回は「駅すぱあとWebサービス無償版」を呼び出しするので、 API Gateway は HTTP Proxy として動作するように設定します
Integration type は HTTP Proxy を選択し HTTP method を GET に Endpoint URL に 「駅すぱあとWebサービス無償版」のエンドポイントを設定します
この際に Endpoint URL にはリクエストパラメータを含めずに設定します
すべての設定が終わったら [Save] ボタンをクリックして先に進みます
Integration type については他に Lambda Function と AWS Service Proxy が選択できそれぞれ入力項目が異なります
Method の設定をしてみる
Method の追加が終わると以下の Method Execution 画面が表示されます
これはMethod 設定のダッシュボード的な画面で各項目の設定が表示され、各項目へ設定画面に遷移できます
各項目については
- 「Client」はそのまま呼び出し元のクライアントを指します
- 「Method Request」と「Method Response」については、実際にクライアントがアクセスするAPI Gateway で作成したAPIのリクエストとレスポンスになります
- 「Integration Request」と「Integration Response」については、今回はHTTP Proxyとして動作するので、originに対してアクセスするためのAPI リクエストとレスポンスになります
- 「エンドポイント」は今回はorigin サーバのエンドポイントを指します
Method Request を設定してみる
Method Request のリンクをクリックして詳細設定画面に移動します
URL Query String Parameters 項目の設定を行います。 URL Query String Parameters を展開して Add query string リンクをクリックして「name」と「key」を追加します
追加後にキャッシュを行いたい場合は Caching 項目にチェックを付けて下さい
Integration Request を設定してみる
続いて Integration Request のリンクをクリックして詳細設定画面に移動します
この Integration Request 項目では、前述の Method Request で受け取ったリクエストの内容を実際のorigin であるエンドポイントに渡す際の値のマッピング設定を行います
今回は Method Request と同様に URL Query String Parameters の設定を行います。URL Query String Parameters を展開して Add query string リンクをクリックして「name」と「key」を追加します
追加の際に Mapped from を入力しますが、入力フォーマットが決まっていて
method.request.{"path" | "querystring" | "header"}.{param_name}.
E.g. method.request.querystring.myparam
の形式で入力します。今回は method.request.querystring.name と method.request.querystring.key になります
この辺りはパススルーの設定や Nameが同一でいいなら簡単に自動生成してくれるとかあるとさらに便利になりそうなので今後に期待です
Mapping Templates については今回XMLを取得することになるので Content-Type に application/xml を指定してみました。
APIのテストを実行してみる
ここまで設定が終わればテスト出来るはずなのでテストを実行してみようと思います。以下の画面で TEST リンクをクリックして Method Test 画面に移行します
Method Test 画面では Query Strings の name と key を指定します。今回は name は駅名となるので「高円寺」を、key は駅すぱあとWebサービス無償版へのアクセスキーになるので発行されているキーを指定しました。
Query Strings の入力が終わったら [Test] ボタンをクリックしてテストを実行します。実行が終わると Response Body を始めとして Response Headers と Logs もその場ですぐに確認できますので非常に便利です
これで設定は完了っぽいのですが HTTP Proxy として動作させている場合には Response ヘッダーが気になります。特に駅すぱあとWebサービス無償版では日本語文字列を戻しているので Content type ヘッダーが適切でない場合、文字化けが起こる可能性があります。
エンドポイントに普通にアクセスすると↓なヘッダー情報が戻ります。その中で必要なのは Content-Type: application/xml;charset=utf-8 となるので、これを付加してみたいとおもいます
Method Response を設定してみる
手っ取り早く固定値で指定をしてみたいと思います。Method Response のリンクをクリックして詳細設定画面に移動します
Method Response 項目画面で Http Status の 200 左側にあるマークをクリックして詳細を展開します。その中で Response Models for 200 項目を編集を行います。Content type にはデフォルトで application/json が指定されていると思うのでこれを application/xml;charset=utf-8 と入力して保存します。Models はそのまま Empty としました。
これでレスポンスヘッダーにこの Content type が付加されることになるので文字化けは起こらなくなります
しかし、これでは固定値なのでエンドポイント側の仕様が変更された場合に困りますし、ヘッダーなので変更はあると思った方がいいのでエンドポイントのヘッダーをマッピングする方法を試してみます
まず同じく Method Response 項目画面で Response Headers for 200 項目に Add Header リンクをクリックして Name を追加します。ここでは Content-Type を指定します。また、Response Models for 200 の項目は必要ないので削除します。
このままではエンドポイントのレスポンスヘッダーとのマッピングが行えないので続けて次の設定を行います
Integration Response を設定してみる
マッピングの設定は Integration Response の詳細設定画面で行います。先に Method Response の設定を行わないとマッピング設定出来ないのは結構わからなかった・・・これ今後はどっち側からでも設定できるようになると嬉しいですねぇ
Integration Response 項目画面で HTTP status regex の - 左側にあるマークをクリックして詳細を展開します。Header Mappings の項目には先ほど Method Response で追加したヘッダー項目が Response header の欄に入力済になっているはずです。この Mapping value 欄に追加を行います。
追加する項目はエンドポイントのContent-Typeヘッダーなので integration.response.header.Content-Type と入力してマッピングを設定します。
あとは、前述のTESTを行いヘッダーとして意図したものが出力されているか確認します。これでヘッダーのマッピングを行うことが出来ました。先に Method Response の設定 からというのを忘れないようにしないと！
Deploy APIを実行してみる
Resources ペインの右側にある青い [Deploy API] ボタンをクリックしてデプロイ項目の詳細画面に移動します
デプロイ先に関する設定を行います。Deployment stage は新規のデプロイなので New Stage を選択し、必須項目の Stage name には例の通り prod と入力します。この名称は URL の一部として利用されることになります。最後に [Deploy] ボタンをクリックしてデプロイを行います。
2度目以降は既存の Deployment stage が選択可能になるので、同じ場所にデプロイを行う際には選択を行います。
Stages 画面にて表示されている Invoke URL がAPI Gateway 経由でアクセスする際のエンドポイントになります。先ほど入力した prod という名称が利用されていることも確認できます。
この状態で公開され利用できますのでブラウザで表示してみました。
文字化けもなくデータが取得できることが確認出来ました。
まとめ
- 弊社の「駅すぱあとWebサービス無償版 」へのHTTP proxy として設定してみた
- マネージメントコンソール上からの設定で簡単に利用できる
- API Gateway を使うことによって運用面での煩わしい部分を軽減できそう
- API Gateway が制約になることにより形が統一出来る可能性がある
- 形が統一・整理出来るとこれも運用面での効果は大きい
- UIが非常に操作しにくい
- UIで値が更新されたりされなかったりするのはカイゼン期待
- Saveしないと反映しないページとしなくてもいいページと操作の統一感が欲しい
- 細かい所は色々あるが、とにかく楽しいしワクワクするサービスなのでどんどんアップデートしてほしい！
以上。
更に詳しくAPI Gatewayが知りたい方は当然ながら例のブログで！
AWS Black Belt Tech Webinar Amazon API Gateway の資料も公開されてました！
あと、このエントリーとは別にアクセスを流すところまで書いてます！
