2
私は、バックエンドサーバレスWeb APIを構築するプロジェクトを進めています。 AWS api gateway/lambdaデベロッパーガイドでこれらのドキュメントを読んだ後は、私が使用できるさまざまな方法で完全に混乱しています。aws APIゲートウェイlambdaを使用してWebバックエンドAPIを構築
私はチュートリアルや、オンライン上ではなく、まだ混乱して、両方見つかったいくつかの解決策を試してみた
...、要求、応答、プロキシを含むすべてのWebのものに非常に新しいです。 APIゲートウェイインテグレーション要求に
- 、統合型の下で、私はAWSのサービスを選択した場合、その後、私はまだラムダを選択することができ、「ラムダ関数」と「AWSサービス」があります。違いはなんですか？ラムダを選んだ場合、「ラムダプロキシ統合を使う」を選ぶことができます。「プロキシ」を研究しましたが、私は考えましたが、ここでも非常に混乱しています。私の実験では、 "lambda proxy integration"を選択した場合に限り、 "event"オブジェクトの中でリクエストを得ることができます。時々ウェブブラウザはラムダからの応答をレンダリングすることができ、APIゲートウェイ内でいくつかの設定が必要になることがあります。
私の場合、どのようなソリューションを使用するのが最適ですか？
@Pano：単一のラムダ関数が複数のHTTPメソッド（GET、PUT、DELETEなど）と複数のパスからリクエストを受信するようにするには、提供されているinfoマークに加えて、 "lambda proxy integration" '/ {proxy +}'リソースパス（これはルートパスの下の任意のパスを取得します）。このオプションでは、ラムダ関数は、すべてのHTTP情報（メソッド、パス、ヘッダーなど）を含む要求に対して、標準のメッセージ形式を受け取ります。次に、リクエストを処理する方法を決定します（基本的に独自のルーティングを実装します）。 –
異なるラムダ関数にルーティングされた異なるHTTPパスとメソッドを持つHTTPメソッド用のAPIゲートウェイとして機能させる場合は、標準の "ラムダ関数"統合要求がより適切です。 –
これらは両方ともサーバレスAPIを実装するための有効な方法であり、ルーティング、配置、ラムダ関数（さまざまなメソッドに複数の言語を使用したいと思っていますか？）などを処理する方法にアーキテクチャの決定が下がります。 –