Is it possible to have AWS's API gateway route based on query string parameters?
So for example:
api.com/stuff?version=1.0
will route to:
https://endpoint.com/mystuff
and
api.com/stuff?version=2.0
will route to:
https://endpoint.com:8080/mystuff
So far I haven't seen anything for this. I can send custom query string parameters along to my endpoints, but I don't seem to be able actually to do anything with them. If it's not possible, have requests been made for this? I can do this through lambda but I would really like to make sure this can't be done through AWS API Gateway first.
You cannot route based on your query parameters, (but it is possible to do the other way around although seems out of your interest).
You can pick "Use Lambda Proxy integration" option and in your method integration request.
Then, in your lambda you use
#python
event['queryStringParameters']
to access you query string parameters to do whatever you like.
No, unfortunately you cannot route the requests base on route parameters. I'll suggest to use the API Gateway stages instead. You can deploy multiple versions of the same API and differentiate them base on the root part of the path
https://domaincom/v1/....
https://domaincom/v2/...
Related
I would like to specify a dynamic subdomain in an Integration Request in API Gateway, but the UI is telling me that the URL is malformed. I can add this parameter to the path of the URL with no problems (although I still get the warning "the endpoint you have entered contains parameters that are not defined in the resource path"). Is this mapping to subdomain possible using API Gateway, or do I need a lambda to accomplish this? Thanks
I couldn't get this to work, so I assume it's not supported. I ended up making a different Gateway for each subdomain (I only have a few) and using a lambda to switch between them. You could also use a lambda without a a Gateway if you have many different subdomains.
Here's my situation. I have 2 AWS lambda functions that I want to use under one subdomain route let's call it api.mywebsite.com. To get it setup I made all the necessary changes to the certificate manager, api gateway, dns records and all that. The subdomain works great with one lambda function. However, when I try to add the second lambda function on API mappings I get errors like cannot get, or "Missing Authentication Token". I cannot get this to work with multiple lambdas.
The following is the setup:
Custom Domains setup:
production-mywebsite-api setup:
production-mywebsite-payments-api setup:
Do you know if it's possible to have one domain working for various lambda functions? Like lets say the domain is api.mywebsite.com but I have 1 lambda that can be reached on api.mywebsite.com/lambda1 and another lambda function that can be reached on api.mywebsite.com/lambda2?
It turns out that the issue that I was having was due to deploying separate lambda functions to separate api getaway configurations. As you can see form my post I had different configurations for both of them. This is like fedonev pointed out a bad practice.
After reading this article and unifying my lambda functions under one api gateaway configuration on deployment I was able to deploy all of them to the same subdomain.
I have a custom domain set up in AWS API Gateway. My intention is to use "API mappings" to send traffic for different API versions to their respective API Gateways, e.g.:
GET https://example.com/v1/foo is sent to an API gateway "APIv1" ($default stage) via an API mapping on the custom domain with path="v1".
GET https://example.com/v2/foo is sent to an API gateway "APIv2" ($default stage) via an API mapping on the custom domain with path="v2" (not shown)
The HTTP APIs themselves are configured with a single route /{proxy+} and an integration that sends requests to a private ALB:
This setup works fine as far as routing traffic goes, but the problem is that when the request makes it to the actual application, the routes the application receives are like /v1/foo instead of just /foo, which is what the app is expecting.
I've played around with different route matching and parameter mapping (of which I can find almost no examples for my use case) to no avail.
I could change my app code to match the routes that AWS is sending, but the entire point of this was to handle versioning using my AWS stack and not app code. Do I have another option?
If you create a resource called /foo and the proxy resource inside it, when you set integration you can define which path to pass and the {proxy} will have just the part after /foo, ignoring the v1 entirely.
See an example below.
In this case it is ignoring everything before v1 and it is also rewriting the integration to /api/{proxy}.
It will receive a request as GET https://example.com/abc/xyz/v1/foo and will forward to backend as GET https://example.com/api/foo.
Update
It can't be done via VPC Link, but we can use public ALB almost like private, like the explanation below.
It explain about CloudFront, but the same is valid for API Gateway.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
It's totally possible. You just need to use parameters mapping for this. Using the AWS UI it would be:
I would like to use you AWS API Gateway as a single entry point to my backend which will proxy (redirect) request to different microservices based on URL prefix. However before to do proxy it would be nice to have lambda which may check requests and make a decision if allowed to make proxy or it's better to make a response imidiatly, so, in another word, I would like to have AWS lambda as middleware. Is it possible to do?
Short answer
Yes, but don't do it. There are other solutions.
Explanation why you shouldn't do it
You can use a lambda in between your containers and API gw but using a lambda as a 'middleware' is an antipattern, you will have to pay double by making your lambda wait on your microservices response.
Other solutions
If you want to handle authentication or check headers and cookies you should use a lambda authorizer.
For your use-case you can make use of an application loadbalancer. That can do path redirects to different target groups.
https://aws.amazon.com/premiumsupport/knowledge-center/elb-achieve-path-based-routing-alb/
It might make sense in having a library that is shared by the different microservices that does the early response or request checking.
Not sure what is your real goal and use case but if you elaborate more on what you'd like to achieve, I might can help.
IMHO this would be the job of API Gateway - based on different URIs & HTTP Methods you may forward the request to different lambdas. You can also check /validate your request params/body and/or add Authorizers (including a Lambda).
It would be interesting to know more about the use case and if the API GAteway would be suitable for it
I am trying to orchestrate UI calls using step function with the minimal impact. Currently I have a lambda function that can be called using different URLs via API gateway, for instance, following URLs are used to call the same lambda:
http://base.url/orders/get/order/{userid}
http://base.url/orders/get/allorders/
I know that it isn't a best practice for lambdas, but we have what we have. Now I need to add a step function between API gateway and lambda to orchestrate calls. I need step function to be able to call step function using these urls, but I cannot understand how to do that.
Here are some links that I already checked:
https://docs.aws.amazon.com/step-functions/latest/dg/concepts-input-output-filtering.html
https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-paths.html
https://docs.aws.amazon.com/step-functions/latest/dg/connect-parameters.html
Is there a way to do what I need to do?
It sounds like you just need to format the message to the lambda in a way that looks like what would be coming from the API Gateway. If that's the case you can see what an API Gateway request would look like by selecting Amazon API Gateway AWS Proxy from the lambda test events in the console. From there you should be able to modify the payload to match your needs.