Amazon API Gatewayの設定の構造

　Amazon API Gatewayの登場で、2Tier-Architectureのピースが揃ったように思えます。いろいろ試してみたいのですが、ちょっと設定の構造が初見でよく解らなかったので一旦整理してみます。理解が間違っていたら、是非指摘してください。

Amazon API Gatewayの用途と構造

---

　まずは、Amazon API Gatewayの公式ドキュメントを眺めてみます。幾つかの用語が出てきています。API,Resource,Method, Method's Settings,Models and Mapping Templates, Stagesまず最初の4つを整理してみます。

　まずAPIを作ります。APIは、オブジェクト指向でいうところのクラスのようなものでしょう。クラスの中に、Resourceを作ります。リソースは、APIにアクセスする為のパスです。まずはデフォルトの/（ルート・ディレクトリ？）を作り、任意にサブディレクトリのような感じで複数作っていきます。
　リソースを作ると、次にMethodの設定を行います。Methodoは、HTTPのプロトコルに対応していて、GETやPOSTの他にHEADやPUTなどが作成します。現実的には、GETとPOSTだけを使うことになるのではと思います。なお、１つのリソースに対して、設定できる同一種別のMethodは１つのみです。/getDataというリソースに対しては、GETは1つだけ設定できます。またPOST等の違うメソッドも設定出来ます。設計上は、1つのリソースに1つのMethodにしておいた方がよいと思います。
※RESTのURIは何を表現するということで、名詞を使うらしいです。そして、どうするという部分を表現するのがMethodとのことでした
　最後にメソッドの設定です。ここがAPI Gatewayの肝になります。設定としては、Lambda Function, HTTP Proxy, AWS Service Proxyの3種類が設定できます。基本設定では、Lambda FunctionとHTTP Proxyを設定でき、Advance SettingでAWS Service Proxyが選択できます。この辺りにAWS側の意図が少し見えてきます。

StagesとModels

---

　StageとModelもAPIにひも付きます。Stageは、利用用途です。例えば、本番用やテスト用など、URLやキャッシュ・ログ・監視やバーストの上限などを変更できます。そもそも、テスト用などでAPI Gatewayの接続先が切り替えられるか気になるところですが、画面コンソールを見る限りは、できなさそうです。もう少し継続調査します。
　次にModelです。これは、API Gatewayの接続先からの返り値をマッピングする為のモデルです。返り値としては、JSONに変換して出力する形になります。デフォルトでは、エラーと空だった場合のものが用意されています。

Error

{
  "$schema" : "http://json-schema.org/draft-04/schema#",
  "title" : "Error Schema",
  "type" : "object",
  "properties" : {
    "message" : { "type" : "string" }
  }
}

Empty

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title" : "Empty Schema",
  "type" : "object"
}

　API Gatewayを実装していく場合は、ひたすらこのモデルを定義していく形になるのではと思います。恐らくAWS Service Proxyの場合は、ある程度テンプレート的なものが用意されていくと思いますが、それでもデータの型によってそれぞれ違ってきます。コンソールで試しに作っていたのですが、これは最終的にはコードとして管理しないと手に負えなくなる予感がします。

AWS Service Proxyの利用

---

　AWS Service Proyについては、まだ余り試せていません。DynamoDBの結果などをそのまま取得できれば胸熱です。このAWS Service Proxyについては、IAM Roleを利用して権限設定をします。ロールの設定の際に、Principal（信頼関係）の設定が必要なのですが、現状では選択肢としてAPI Gatewayがでてきません。次のような感じで、apigateway.amazonaws.comを設定しましょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

まとめ

---

　まだ全然時間が取れていないので、未知数の部分が多いですが、昨年のLambdaに引き続き楽しいサービスなのは間違いないです。最近は、サーバを立てずにどうやって実現するかを考えているのですが、その重要な要素の1つになります。一方で、API Gatewayの実体は、ApacheやNginxのrewrite proxyのようなものと、AWS系のリソースを呼び出せるアプリケーションエンジンの組み合わせと推測できます。当然オーバヘッドはあるので、どれくらいのパフォーマンスなのか測っていく必要があると思います。（誰かやってくれると思うけど。）

参照：docs.aws.amazon.com

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく