API Gateway のアップデート – API 開発を簡素化する新機能

Amazon API Gateway で、堅牢でスケーラブルなアプリケーションバックエンドの構築と実行を簡単に素早く最近追加された使用プランで、API に関与するパートナー開発者のエコシステムを作成することができます。では、いくつかの用語を確認しながら始めましょう。

エンドポイント – HTTP リクエストに応答する URL (API Gateway によって提供される) です。これらのリクエストは、GET、PUT、POST などの HTTP メソッドを使用します。

リソース – エンドポイント内にある名前の付いたエンティティで、階層パスと呼ばれます。

動作 – 特定のリソース上で、HTTP リクエストに対応してコードが HTTP メソッドを使用して実行するアクションです。

統合 – エンドポイント、リソース、および HTTP メソッドと実際のアクションとの間でやり取りされる API Gateway マッピングです。

現在、API Gateway が提供する統合モデルを拡張して、新しい API エンドポイントの構築と既存のアプリケーションの移植を容易にするための複数の新しい機能をサポートしています。

greedy パス変数 – 一般的なパス ( /store/ など) に分類されるリクエストのグループのパスと動作を個別に指定する代わりに、パスへのすべてのリクエストを傍受してそれらを同じ機能にルーティングする、「greedy」ルートを指定できるようになりました。たとえば、単一の greedy パス (/store/{proxy+}) は、 /store/list-products, /store/add-product、および /store/delete-product) に対するリクエストを傍受します。

ANY メソッド – それぞれの HTTP メソッド (GET、POST、PUT など) に個別の動作を指定する代わりに、catch-all ANY メソッドを使用して、すべてのリクエストに対して同じ統合動作を定義できるようになりました。

Lambda 関数統合 – 新しいデフォルトのマッピングテンプレートで、すべてのリクエストを Lambda 関数に送信し、戻り値を HTTP 応答に変換します。

HTTP エンドポイント統合 – もう 1 つの新しいデフォルトマッピングテンプレートで、すべてのリクエストを HTTP エンドポイントに送信し、その応答を変更せずに返します。これにより、わずかのセットアップ作業を行うだけで API Gateway を HTTP プロキシとして使用できます。

詳しい内容を見てみましょう。

Greedy パス変数
新しい e-コマース API を作成しているところだとしましょう。次のように開始します。

次に、 /store リソースを作成します。

次に、greedy パス変数を使用して、 /store 内のリソースに対するすべてのリクエストを傍受します (プロキシリソースとして設定されていることも確認する必要があります)。

なぜなら、 {proxy+} がサブリソースのリクエストを実際のリソースにルーティングするため、リソースパスの最終要素として使用される必要があるからです。これ以外の場所で使用するのは無意味です。 {proxy+} はあらゆる深さのパスに一致させることができます。上記の例は、 /store/us/clothing, /store/us/clothing/children などにも一致します。

プロキシは Lambda 関数または HTTP エンドポイントに接続できます。

ANY メソッド
HTTP メソッドでリソースとメソッドを定義するときに、それぞれの HTTP メソッドに対して個別の動作を指定する必要はなくなりました。

代わりに、ANY を選択して、リソース上のすべてのメソッドに対して同じ統合動作を使用することができます。

これにより、セットアップがより明確でシンプルかつ容易なものになります。お使いのコード (リソース上のすべてのメソッドに対する統合ポイント) は、メソッド名を調べて適切なアクションを実行します。

ANY メソッドは、上記のように greedy パス変数を使用すると自動的に作成されます。これは個別のリソースにも使用できます。メソッドを作成してその設定を変更するだけで、個別のメソッドの設定を上書きすることができます (DELETE を別の方法で使用するなど)。

Lambda 関数統合
Lambda 関数を使用して動作を実装するのがこれまでになく簡単になりました。新しい組み込みの Lambda 統合テンプレートは、HTTP リクエスト要素 (ヘッダー、クエリーパラメーター、ペイロード) を関数が直接使用できる形式にマップします。テンプレートは、関数の戻り値 (ステータスコード、ヘッダー、本文要素) を適切に構造化された HTTP 応答にマップします。

ドキュメントからコピーしたシンプルな関数を次に示します (「プロキシ統合のための Lambda 関数」を参照)。

この関数を次のように /store に接続します。

次に、それをデプロイして (デプロイに関する説明は示しません)、次のようにテストします。

関数が予想通りに実行され、コンソールに応答の本文、ヘッダーが表示され、ログファイルが作成されます。これが最初の部分です。

次に Lambda コンソールに移動して、使用した関数の CloudWatch ログを調べます。

ここにあるとおり、関数の 10 行目に黄色で強調表示したメッセージがあります。

このように、マッピングや変換の設定に時間をかけずに、API リソースで HTTP リクエストに応答する Lambda 関数を作成することができるようになります。事実、Lambda コンソールに新機能を追加したことで、このプロセスがいっそう簡単になりました。新しい Lambda 関数作成の最初のステップの 1 つとして、API Gateway エンドポイントを設定できるようになりました。

HTTP 関数統合
また、EC2 インスタンスまたはオンプレミスで実行されている HTTP エンドポイントに API リクエストを送信できるようにもなりました。もう一度繰り返しますが、マッピングや変換を設定する手間はもう必要なくなりました。代わりに、統合タイプに HTTP を選択して HTTP プロキシ統合をクリックし、エンドポイントの名前を入力するだけです。

HTTP メソッドで ANY を選択すると、受信されたリクエストのメソッドがエンドポイントにそのまま送信されます。ANY を選択しなかった場合は、呼び出しの一部として示される値にメソッドが設定されます。

今すぐ利用可能
上記の機能は今すぐご利用いただけます。無料で今日からお使いいただけます。

— Jeff;