GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。
#必要性
よく言われることだが、コードは書いた分だけバグの可能性が上がるので、極力実績のあるOSS、数多のクラウドベンダーによって提供されるIaaS、PaaS、SaaSを使用して自前のコーディングを最小限にとどめたい。また、車輪の再発明もしたくない。その方針で設計、プロトタイピングをしているが、
今のところ、MicroserviceをRESTまたは、メッセージングで繋いでいく方向で検討中。
拡張性、メンテナンス性やモバイルやアプリ（MBaaS）のこと等も考えると、どうしてもGatewayが必要になってくると思う。
認証を一手に引き受けてくれるところも嬉しい。
以前のプロジェクト（よくある ちゃぶ台返しをくらって実現できなかったが）では
あたりをGKEで展開すればと考えていたが
Amazon API Gatewayを使ったことがなかったので、チーム全員で使ってみながら考えてみた。
とりあえず使ってみる
とりあえずブリッジ的なAPIを作ってみる。
色々確認、モニタリングしながら使ってみたいので、ブリッジ先はmockbin。
モックAPIをGUIで作成して、モニタリングできる。
以前、ブリッジwebサービスを作ったときに使いました。
久々に使ったけどこれ便利だなぁ。
create API
こちらの Amazon API Gatewayから
リソース、メソッドの作成。
なかなか直感的。この図だけで説明がいらない。
直感的かどうかは、個人的にかなり重要視するポイントです。
「メソッドリクエスト」のパラメータセクション。
とりあえずfooというパラメータを定義してみる。
（キャッシュや、パラメータをバインドする必要があるときに使います。）
「統合リクエスト」のパラメータセクション。
上で定義したfooが定義されているので、それをbarに変えてみる。
Gatewayにfoo=abcでリクエストすると、mockbinにはbar=abcでリクエストされる。
あとはDeployのみ。以上。
#所感
直感的で、使いやすい。
ただし、認証がかなり直感的ではない。幾つかあり、我々はIAM（ Identity and Access Management ）認証を使っていくのだが、、、、後々書きます。
認証部分はメンテナンスしていく上でわりと使用頻度が高いので、より直感的に簡単にしたい。（もちろん強固に）
もっと直感的なGatewayないかなと思っていたところ、Googleの営業の方より、Apigeeを教えてもらう。
これぞ求めていたものかも。。。
いじっているので、感想は後ほどシェアします。
シェアはこちらです。
それでは。