【要約】API Gateway → Lambda の間で何が行われているかを易しく解説 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
API GatewayとLambdaの連携において、両者の「間」で行われる処理がブラックボックス化しやすい。具体的には以下の課題がある。
- ・リクエストのバリデーションや変換の仕組みが不明瞭。
- ・非プロキシ統合における、4つのフェーズの役割分担が複雑。
- ・適切な統合方式の選択が、開発効率や実装負荷に直結する。
// Approach
統合方式の違いに基づき、以下の2つのアプローチを提示する。
1.非プロキシ統合による詳細制御
- ・メソッドリクエスト：認証・認可やパラメータ検証を実施。
- ・統合リクエスト：マッピングテンプレートを用い、データをJSON等へ変換。
- ・統合レスポンス：バックエンドの応答をクライアント用に加工。
- ・メソッドレスポンス：返却するステータスコードやモデルを宣言。
2.プロキシ統合による簡略化
- ・API Gatewayの処理を最小化。
- ・Lambda側で以下の形式を遵守してレスポンスを構築。
{"statusCode": 200, "headers": {...}, "body": "..."}// Result
開発要件に応じた適切な統合方式の選択が可能となる。
- ・プロキシ統合：Lambda側で制御を完結させ、設定コストを削減。
- ・非プロキシ統合：API Gateway側でバリデーションや変換を行い、Lambdaの責務を軽減。
Senior Engineer Insight
> 実務では、開発速度と実装の単純さを優先し、プロキシ統合を選択するのが一般的だ。Lambda側でレスポンス形式を制御する手間はあるが、全体的な構成は極めてシンプルになる。一方で、大規模トラフィックや厳格なバリデーションが求められる環境では、非プロキシ統合の価値が高まる。Gateway側でリクエストの検証や変換を完結させることで、Lambdaの実行時間を短縮し、コスト最適化に寄与できるからだ。設計時には、単なる「楽さ」ではなく、責務の分離とコストの観点から統合方式を決定すべきである。