Support for Http API

[jcarter3]

Are there plans to support the Http API v2 events?

https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

[charlietran]

V2 support would be great! Currently, HTTP API is working fine for us with this library, as long as we set the PayloadFormat in our Lambda Integration to 1.0. Cloudformation YAML example:

  HttpApiInteg:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref YourHttpApi
      PayloadFormatVersion: '1.0'
      IntegrationType: AWS_PROXY
      IntegrationUri: !Join
        - ''
        - - !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/
          - !GetAtt YourAPILambdaFunction.Arn
          - /invocations
      TimeoutInMillis: 15000

[dnagir]

As it stands now (without the workaround above), the request URL in ServeHTTP receives Path: / on all resources.

[sapessi]

Hi All, we will look into this as soon as possible. We'll use this issue to track progress.

[aereal]

Hi, is any activities about this issue going on?

If not, I have an intention to submit Pull Request about the issue: https://github.com/awslabs/aws-lambda-go-api-proxy/compare/master...aereal:proxy-v2?expand=1 (just WIP)

Currently methods for payload format V2 are implemented as almost copy of V1's. This is very straightforward way but symmetrical for V1's implementations.

The change is working in progress yet, but any comments are welcome. If it will be ready, I'll submit it.

[rockey5520]

I have spent a day debugging why lambda is receiving only "/" for path and about to raise an issue asking for help and am glad to find this issue raised already.

I would be super grateful if there will support for v2 in the near future, in meantime mentioning this about this issue on Readme will help others save time in debugging :)

[aryounce]

@rockey5520 Have you taken a look at the support for V2 added in https://github.com/awslabs/aws-lambda-go-api-proxy/pull/91/files ? I had the same issue and it was from not using the correct structs (from both aws-lambda-go-api-proxy and aws-lambda-go.

[rockey5520]

Thanks, @aryounce I have not noticed it. I will check out this. Very much appreciated.

[rockey5520]

Hey @aryounce ,

could you please give me an example how to use v2 ? i could not find the file adapterv2.go in my vendor directory as well

Regards Rakesh

[maslick]

@aryounce what's the status of this issue? Did your PR #97 and #99 fix the issue? I can't make it work though - all endpoints are forwarded to the root /.

@rockey5520 The problem seems to be in the payload version - v2 is not supported by aws-lambda-go-api-proxy. The workaround with the serverless framework is to explicitly downgrade it to v1 - see here.

service: test
frameworkVersion: '2'

provider:
  name: aws
  runtime: go1.x
  stage: ${opt:stage, 'dev'}
  region: eu-central-1
  lambdaHashingVersion: 20201221
  apiGateway:
    shouldStartNameWithService: true
  httpApi:
    cors: true

package:
  exclude:
    - ./**
  include:
    - ./bin/**

functions:
  health:
    handler: bin/http
    memorySize: 128
    events:
      - httpApi:
          path: /health
          method: get

resources:
  extensions:
    HttpApiIntegrationHealth:
      Properties:
        PayloadFormatVersion: '1.0'

[rockey5520]

Thanks, @maslick for the workaround. unfortunately here, in this case, am using AWS SAM rather than serverless. I will consider this approach for the next project to use serverless

[maslick]

@rockey5520 if you're using SAM, then look at what @charlietran proposed (CloudFormation): basically you need to explicitly set

PayloadFormatVersion: '1.0'

SAM is just an extension to the vanilla CloudFormation, so I believe it should work in your SAM template as well.

[rockey5520]

Hey @maslick yes exactly that was how I got around this problem but would love to use the latest PayloadFormatVersion when this is fixed :) thanks for the pointer though really appreciate