/var/log/messages

Aug 29, 2018 - 5 minute read - Comments - devops

How to use Amazon API Gateway {proxy+}

以下なドキュメントを機械翻訳したので以下に控えを。

Background

AWSで私が気に入っているツールの1つがAPI Gatewayです。 私はそれを使用して、いくつかの内部ツールとトレーニング用のラボを構築しました。 API Gatewayを使用していない場合は、こちら から始めてください。

AmazonのAPI Gatewayは、HTTPエンドポイントをリソース(AWSとオン・プレミアム)の前に置く比較的簡単な方法を提供します。 API Gatewayでは、APIのHTTPリソースのさまざまな部分を定義して処理するいくつかの異なる方法が提供されます。

もう1つのクールなAPIゲートウェイ機能は、すべてのHTTPメソッドを処理できる単一のメソッド定義を可能にするANYメソッドです。 例えば。 GET、POST、PUT、DELETEなどはすべて同じバックエンドリソースに送信されます。

{proxy +}とANYメソッドの間で、すべてのAPIリクエストを処理できる単一のリソースを定義できます。 これは、バックエンドリソースがすべての意思決定を処理したいが、API Gatewayの機能(スケーリング、スロットル、許可、要求の検証、https)を利用したい場合に非常に便利です。

greedy {proxy +}パスを使用するには:

  • Navigate to your API HERE.

    • Press Actions
    • Press Create Resource
    • Select Configure as proxy resource
  • Then create the appropriate ANY method:

    • Press Actions
    • Press Create Method
    • Select Use Lambda Proxy integration
    • Select Region
    • Select Lambda Function
    • Press Save

プロキシリソースと他の2つのリソースタイプを使用する主な違いは、統合応答全体(適切なヘッダー/ステータスコード/本文)に対する応答です。 そのため、バックエンドリソースは、HTTP要求に対する適切な形式の応答を返す必要があります(下記のAPIゲートウェイのセクションを参照)。

{proxy +}リソースの使い方を説明するために、私は楽しい例を考え出しました。 また、カスタムトークンを作成して、長いS3 URLやその他のランダムなドメインを難読化できるようにしたいと思っていました。 サーバーレスのbit.lyクローンを考えてください(たとえば、トークンをURLのbit.ly/neatにリダイレクトするなど)

サーバーレスURLリダイレクトツールは、以下のサービスで構成されています。

API Gateway

  • API Gatewayは、プロキシパス/ {proxy +}経由でWebサイトを提供します。
  • プロキシ+を使用すると、リソースパス全体(example.com/resource/subresource/subsubresource/)、クエリ文字列パラメータ、ヘッダーなどを含むJSONドキュメントとしてバックエンドリソース(この場合はLambda関数)にすべてが渡されます。 { “body”: “{\“test\”:\“body\“}”, “resource”: “/{proxy+}”, “requestContext”: { … “identity”: { … }, “stage”: “prod” }, “queryStringParameters”: { “foo”: “bar” }, “headers”: { … }, “pathParameters”: { “proxy”: “path/to/resource” }, “httpMethod”: “POST”, “path”: “/path/to/resource” }

{proxy +}リソースを使用する場合、APIゲートウェイは特定のリターンペイロード(下記参照)を要求します。 それ以外のものが返された場合、API Gatewayは500エラーを返し、不正な形式のラムダ応答をログに表示します。 あなたのコードは、あなたが達成しようとしているものに基づいて適切なステータスとヘッダーを策定する必要があります。 この場合、この関数は、与えられたトークンが存在するかどうかに応じて、statusCodeを200または301に戻します。

{
        "statusCode": 200 |301|4XX|5XX,
        "headers":{
          "Content-Type": "text/html",
          ...
        },
        "body": "..."
    }

Lambda

この例の使用例では、私はLambdaを使用して、リダイレクトマイクロサービスのフロントエンドとバックエンドの両方として機能しました。 GETメソッドは、HTMLとJSのフロントエンドを処理します。 POSTは、destination_urlの検証と新しいエントリDynamoDBの作成を処理します。

ここ でコードを見ることができます。

注:単純なユースケースですが、私が書いたのは、実際にはモノリシックなアプリケーションや関数のほうが多くあります。 これにより、APIを破壊してテストするのが非常に簡単になります。 アーキテクチャの観点からは、通常、それぞれのhttpメソッドごとに異なる機能サービスを持つ方が理にかなっています。

DynamoDB

For this example, I use a simple DynamoDB table with two fields: •id is a quasi-unique 6 digit token, which is used as part of the shortened URL https://…/redirect/ABC123. •destination_url contains the redirect URL.

Conclusion

API Gateway {proxy+} is a powerful tool to that can greatly simplify your front end API. Use it!

Deploy it for your own use Cloudformation Template

SAM Template There is currently a bug with SAM for proxy resources where it doesn’t properly provision API Gateway permissions to your Lambda function. To fix this, follow the steps below:

  • Press on the pencil icon next to the Lambda function:

  • Press the checkbox to the right of the Lambda function

  • A pop-up will prompt you to give API Gateway invocation permissions on your Lambda function. Press OK.