Amazon API Gateway の概念
次のセクションでは、API Gateway を使用するための入門概念について説明します。
- API Gateway
-
API Gateway は以下をサポートする AWS のサービスです。
- API Gateway REST API
-
バックエンド HTTP エンドポイント、Lambda 関数、または AWS のその他サービスを使用して統合されているリソースおよびメソッドのコレクション。このコレクションは、1 つ以上のステージでデプロイできます。通常、API リソースはアプリケーションロジックに従ってリソースツリーで整理されます。各 API リソースは、API Gateway でサポートされている一意の HTTP 動詞を持つ 1 つ以上の API メソッドを公開できます。詳細については、「REST API と HTTP API のどちらかを選択する」を参照してください。
- API Gateway HTTP API
-
バックエンド HTTP エンドポイントまたは Lambda 関数と統合されるルートとメソッドのコレクション。このコレクションは、1 つ以上のステージでデプロイできます。各ルートは、API Gateway でサポートされている一意の HTTP 動詞を持つ 1 つ以上の API メソッドを公開できます。詳細については、「REST API と HTTP API のどちらかを選択する」を参照してください。
- API Gateway WebSocket API
-
バックエンド HTTP エンドポイント、Lambda 関数、または AWS のその他サービスを使用して統合されている WebSocket ルートとルートキーのコレクション。このコレクションは、1 つ以上のステージでデプロイできます。API メソッドは、登録されたカスタムドメイン名と関連付けることができるフロントエンド WebSocket 接続を通じて呼び出されます。
- API デプロイ
-
API Gateway API の特定時点のスナップショット。クライアントが使用できるようにするには、デプロイが 1 つ以上の API ステージに関連付けられている必要があります。
- API デベロッパー
-
API Gateway のデプロイを所有する AWS アカウント (プログラム的なアクセスもサポートするサービスプロバイダーなど)。
- API エンドポイント
-
特定のリージョンにデプロイされる API Gateway の API のホスト名。ホスト名の形式は
です。次のタイプの API エンドポイントがサポートされています。{api-id}
.execute-api.{region}
.amazonaws.com - API キー
-
API Gateway が REST または WebSocket API を使用するアプリケーションデベロッパーを識別するために使用する英数字の文字列。ユーザーに代わって API Gateway が API キーを生成することも、CSV ファイルからインポートすることもできます。API キーを Lambda オーソライザーまたは使用量プランと一緒に使用して、API へのアクセスを制御します。
「API エンドポイント」を参照してください。
- API 所有者
-
API デベロッパーを参照してください。
- API ステージ
-
API (例: 'dev'、'prod'、'beta'、'v2' など) のライフサイクル状態への論理的な参照。API ステージは API ID とステージ名によって識別されます。
- アプリケーションデベロッパー
-
AWS アカウントを持っているか持っていないアプリケーション作成者であり、API 開発者によってデプロイされた API を操作します。アプリケーション開発者は、顧客です。アプリケーション開発者は通常、API キーによって識別されます。
- コールバック URL
-
新しいクライアントに WebSocket 接続経由で接続するときは、API ゲートウェイで統合を呼び出し、クライアントのコールバック URL を保存できます。次に、このコールバック URL を使用して、バックエンドシステムからクライアントにメッセージを送信することができます。
- デベロッパーポータル
-
お客様の顧客による API 製品 (API Gateway 使用量プラン) の登録、検出、サブスクライブ、API キーの管理、API の使用状況メトリクスの表示を許可するアプリケーション。
- エッジ最適化 API エンドポイント
-
主に AWS リージョン全体からのクライアントアクセスを容易にするために CloudFront ディストリビューションを使用しながら、指定されたリージョンにデプロイされる API Gateway API のデフォルトのホスト名。API リクエストは最寄りの CloudFront POP (Point of Presence) にルーティングされます。一般的にはこれによって地理的に分散したクライアントへの接続時間が改善します。
「API エンドポイント」を参照してください。
- 統合リクエスト
-
API Gateway の WebSocket API ルートまたは REST API メソッドの内部インターフェイス。このインターフェイスでは、ルートリクエストまたはパラメータの本文、およびメソッドリクエストの本文を、バックエンドで必要な形式にマップします。
- 統合レスポンス
-
API Gateway の WebSocket API ルートまたは REST API メソッドの内部インターフェイス。このインターフェイスでは、バックエンドから受け取ったステータスコード、ヘッダー、ペイロードをクライアントアプリに返されるレスポンス形式にマップします。
- マッピングテンプレート
-
Velocity Template Language (VTL)
のスクリプト。リクエスト本文をフロントエンドデータ形式からバックエンドデータ形式に変換したり、レスポンス本文をバックエンドデータ形式からフロントエンドデータ形式に変換したりします。マッピングテンプレートは、統合リクエストまたは統合レスポンスで指定できます。コンテキストおよびステージ変数として、実行時に利用できるデータを参照できます。 このマッピングは、統合を通じてヘッダーまたは本文をそのままクライアントからリクエストのバックエンドに渡す、単純なアイデンティティ転換
とすることができます。レスポンスについても同じです。この場合、ペイロードはバックエンドからクライアントに渡されます。 - メソッドリクエスト
-
API Gateway での API メソッドのパブリックインターフェイスであり、アプリケーションデベロッパーが API を介してバックエンドにアクセスするために送る必要のあるパラメータと本文が定義されています。
- メソッドレスポンス
-
REST API のパブリックインターフェイスであり、アプリケーションデベロッパーが API からのレスポンスに求めるステータスコード、ヘッダー、本文モデルが定義されています。
- Mock 統合
-
モック統合では、API のレスポンスは統合バックエンドを必要とすることなく、API Gateway から直接生成されます。API デベロッパーは、API Gateway がモック統合リクエストにどのように応答するかを決定します。そのため、特定のステータスコードとレスポンスを関連付ける、メソッドの統合リクエストと統合レスポンスを設定します。
- モデル
-
リクエストまたはレスポンスペイロードのデータ構造を指定するデータスキーマ。API の厳密に型指定された SDK を生成するために、モデルが必要です。また、ペイロードの検証にも使用されます。モデルは、サンプルマッピングテンプレートを生成して本稼働マッピングテンプレートの作成を開始するうえで役立ちます。このモデルは有益ですが、マッピングテンプレートを作成するうえで必須ではありません。
- プライベート API
-
「プライベート API エンドポイント」を参照してください。
- プライベート API エンドポイント
-
インターフェイス VPC エンドポイントを介して公開された API エンドポイント。これにより、クライアントは VPC 内部で安全にプライベート API リソースにアクセスすることができます。プライベート API はパブリックインターネットからは分離されており、アクセス権限を付与されている API Gateway の VPC エンドポイントを使用してのみアクセスできます。
- プライベート統合
-
クライアントが、リソースをパブリックインターネットに公開することなく、プライベート REST API エンドポイントを介してお客様の VPC 内のリソースにアクセスする、API Gateway の統合タイプです。
- プロキシ統合
-
単純化された API Gateway 統合設定。HTTP プロキシ統合または Lambda プロキシ統合としてプロキシ統合を設定できます。
HTTP プロキシ統合の場合、API Gateway はフロントエンドと HTTP バックエンド間のリクエストとレスポンスの全体を渡します。Lambda プロキシ統合の場合、API Gateway はリクエスト全体をバックエンド Lambda 関数に入力として送信します。API Gateway は、その後、Lambda 関数の出力をフロントエンドの HTTP レスポンスに変換します。
REST API でのプロキシ統合は、プロキシリソースとともに最もよく使用されます。プロキシリソースは、greedy パス変数 (
{proxy+}
など) とキャッチオールのANY
メソッドの組み合わせによって表されます。 - クイック作成
-
クイック作成を使用すると、HTTP API の作成を簡素化できます。クイック作成は、Lambda または HTTP 統合、デフォルトのキャッチオールルート、および変更を自動的にデプロイするように設定されたデフォルトステージを持つ API を作成します。詳細については、「AWS CLI を使用して HTTP API を作成する」を参照してください。
- リージョン API エンドポイント
-
指定されたリージョンにデプロイされ、同じ AWS リージョン内の EC2 インスタンスなどのクライアントに対応する目的である API のホスト名。API リクエストは、CloudFront ディストリビューションを経由せず、リージョン固有の API Gateway API を直接ターゲットとします。リージョン内のリクエストについては、リージョンエンドポイントは、CloudFront ディストリビューションへの不要なラウンドトリップをバイパスします。
さらに、レイテンシーに基づくルーティングをリージョン別エンドポイントに適用して、同じリージョン別 API エンドポイント設定を使用して、同じカスタムドメイン名をデプロイされた各 API に設定し、さらにレイテンシーに基づく DNS レコードを Route 53 に設定してクライアントリクエストをレイテンシーが最も低いリージョンにルーティングして API を複数のリージョンにデプロイすることができます。
「API エンドポイント」を参照してください。
- ルート
-
API Gateway の WebSocket ルートは、メッセージの内容に基づいて、受信メッセージを AWS Lambda 関数などの特定の統合に転送するために使用されます。WebSocket API を定義するときは、ルートキーおよび統合バックエンドを指定します。ルートキーはメッセージの本文中にある属性です。受信メッセージでルートキーが一致した場合、統合バックエンドが呼び出されます。
デフォルトのルートは、一致しないルートキーに対して設定したり、ルーティングを実行してリクエストを処理するバックエンドコンポーネントにそのままメッセージを渡すプロキシモデルを指定したりできます。
- ルートリクエスト
-
API Gateway での WebSocket API メソッドのパブリックインターフェイスであり、アプリケーションデベロッパーが API を介してバックエンドにアクセスするためにリクエストで送る必要のある本文が定義されています。
- ルートレスポンス
-
WebSocket API のパブリックインターフェイスであり、アプリケーションデベロッパーが API Gateway に求めるステータスコード、ヘッダー、本文モデルが定義されています。
- 使用量プラン
-
使用量プランにより、選択した API クライアントは、1 つ以上のデプロイされた REST API または WebSocket API にアクセスできます。使用料プランを使用して、スロットリングとクォータ制限を設定できます。これらは、個々のクライアント API キーに適用されます。
- WebSocket 接続
-
API Gateway は、クライアントと API Gateway 自体の間の永続的な接続を維持します。API Gateway と Lambda 関数などのバックエンド統合の間には永続的な接続はありません。バックエンドサービスは、クライアントから受信したメッセージの内容に基づいて、必要に応じて呼び出されます。