4

I have built 100s of APIs and Lambdas and never had to go through such a discussion.

I always used proxy integration and parsed the parameters in my code using this

x = event['queryStringParameters']
ID   = x.get("param1")
name = x.get("param2")

However, the front-end engineer is arguing that we should follow the recommended naming convention and pass parameters to our APIs as path parameters same as in this link https://restfulapi.net/resource-naming/ After some research, I found that this is basically non-proxy integration and I should configure the param in API GW. I read in many blogs that this is not the recommended way though. but I can not find a clear AWS doc that explicitly prefers proxy integration.

proxy(path param): http://api.example.com/device-management/managed-devices/{id}

non-proxy(query string param): http://api.example.com/device-management/managed-devices?param1={id}

I have been trying to convince him that I have not seen this being used anywhere and that the APIs URLs are used in the app code so why does the look of the API url matter?!!

PLEASE, I need your opinions in this. Tell me what you think?

Data_sniffer
  • 588
  • 1
  • 8
  • 19
  • What exactly is proxy integration you are refering to? Most of the talks I can find is around the "API Gateway Proxy Integration" with Lambda. However, you seem to be refering to the {proxy+} path mapping? – qkhanhpro Jun 29 '21 at 03:45
  • @qkhanhpro Yes, I mean API Gateway Proxy Integration. because this is how I can configure params to be send as path params – Data_sniffer Jun 29 '21 at 03:56

2 Answers2

2

Lambda Proxy Integration sent the request directly from the client to the lambda function without any modifications. It directly maps one URL to one lambda function. Therefore it is not possible to use path parameters with this setup.. Update: It is possible to use path parameters using {path} segment in the URL as described in this AWS documentation

Lambda Integration can modify the request before sending it to the Lambda function also modify the response from the same function before sending it to the client. With Lambda Integration, an API designer has more control over the APIs rather than burying API definitions into the code. It's easy to generate swagger API specification from the API Gateway Velocity Template Language (VTL).

Lambda Proxy Integration is recommended for rapid prototyping but Lambda Integration is recommended for a mature REST API.

Nidin Vinayakan
  • 1,199
  • 9
  • 9
  • Thanks for the good response. Is this your personal opinion or it's an AWS recommendation? if so, could you please share with me the doc link? – Data_sniffer Jun 29 '21 at 04:40
  • 1
    Hi @Data_sniffer, Apologies. I was referring to the old Lamda proxy integration. Now you can use path parameters with the proxy integration. There is no need to go with non-proxy integration just for the path parameters. – Nidin Vinayakan Jul 02 '21 at 09:31
0

Two separate issues here. 1: What is the proper RESTful way to designate a resource and 2: How do you pass path variables from API Gateway to Lambda functions.

For issue #1, I'd side with your front-end developer. RESTful resources are designated through URI's (translation: use path variables). Query parameters are not used for resource identification. There are plenty of articles on REST design going back almost 20 years, which probably explains any intransigence from your front-end developer. I wouldn't expect AWS documentation to weigh in on this, though the entire design of the API gateway is established with RESTful URIs in mind. Swagger inports / exports are much more useful when URIs are an explicit part of the design. For reference, take a look at the Pet Shop sample API (i.e. GET /pets/{id}, not GET /pets?id=x).

For issue #2, You can access that path variable using either proxy or non-proxy integration. For proxy integration, your Lambda code can access the path variables using "pathParameters" (pathParameters.id in the case of the pet shop). I'm not sure if the "pathParameters" key was available when you originally posted your question, which may have led to your conclusion that the more labor-intensive non-proxy integration was the only way to implement this. Reference: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format

Ken Krueger
  • 1,005
  • 14
  • 26