AWS API Gateway Integration Request setup automation - amazon-web-services

I am trying to use the AWS API Gateway+Swagger to route the request to my express backend. I can't figure out how to automate the setup of the integration request as the Swagger file has no details on it.
I'm also having difficulty with the endpoint url parameter when setting my method requests to GET/VPC Link on the integration type
For example:
My api gateway path is /info/car/{model}/aggregate
Now the endpoint url is http://carapi.com/info/car/{model}/aggregate
I have lots of gateway paths all of which are the same paths that my carapi.com site uses, so I don't want to keep retyping the path over and over. When entering in the endpoint url, I was able to simplify not having to type carapi.com by using stage variables turning my endpoint url to
http://${stageVariables.carApi}/info/car/{model}/aggregate
However after reading https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#stagevariables-template-reference
I see that there is also a $context available, but it gives me an error(when I try to call the api in postman, says 'internal server error' for the message) when I try to implement the context (which through that link shows that I can implement the path).
http://${stageVariables.carApi}/${context.resourcePath}
So my question is: how do I automate the setup of Integration requests so I don't have to manually setup each and every one(as I have hundreds of paths)? Is there also anyway to not have to set the paths manually for the endpoints?

I don't know of any solution which is ready to use.
In my project, we wrote a custom solution that downloads the application Swagger json, parses it, adds the required integration and generates another json file. Then we import that into API Gateway. This has been converted as a Jenkins job and runs as a post job of microservice deployment.
Another way is, instead of generating the json, directly call API Gateway APIs and add the integration.

Related

How to solve the OPTIONS 500 error in AWS API Gateway?

I have created a React Application to upload a file to the S3 bucket. To do this, I have created a PUT API from the AWS API Gateway and the API is working well in the POSTMAN. The problem is, when I call the API from my React Application locally (http://localhost:3000), I'm getting a 500 error from the OPTIONS request (Preflight).
I have set the Binary Media Types to "image/jpeg" and When I remove the Binary Media Types, the API returns the 200 response, but then, an empty image is uploaded without its content.
How can I solve this?
This is my Request Integrations of both the PUT method and the OPTIONS method
PUT
OPTIONS
Binary Media Types

why does api gateway with http api using api mapping fail with 404?

I have a custom domain name in AWS API gateway. I am using the same domain for 2 separate API stages. One API stage is REST API, and the other HTTP API.
When I test out my setup, everything works for the REST API. However, the mapping path for HTTP API is not working and I get status-code = 404 Not Found, with 0kb body.
references used:
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-mappings.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html
From my testing in postman, i get the following result when calling the custom domain.
1. {{api.gateway.custom.domain.url}}/foobar - works
2. {{api.gateway.custom.domain.url}}/this-no-work/foobar - 404
3. {{api.gateway.custom.domain.url}}/this-works/foobar - works
does anyone know why (2) gives 404? api-gateway REST API with mapping works while api-gateway HTTP API will return 404 with 0kb body. Is there something I am missing?
note: the (none) path mapping has been added for a sanity check, and I was able to get the expected response.
I had the same problem.
The problem is in the configuration of routers of your application.
When you configure one API mapping in AWS API Gateway, the configured path (this-no-work) is passed to your web application as a prefix of routes.
SO ... if you have one route like this:
/api/foobar
you need configure one more route with the prefix point to the same action:
/this-no-work/api/foobar
A good one is to make one global configuration to your web app.
You can note it enabling the cloudwatch logs of your API Gateway stage and looking into the cloudwatch logs the path property passed from API Gateway to the Web application.
Thanks to answer from #gean-ribeiro, I was able to figure why my HTTP API was returning 404 Not Found.
Turns out it was not an issue with HTTP API. The error 404 Not Found with 0kb body was coming from the API integration sitting behind APIG. Specifically, it was a load balancer using rules based on HTTP path pattern.
By default, any unmatched path pattern will return 404 with text/plain body. this-no-work was a new HTTP API I added, and it did not have the necessary listener rules.
Once I added a new listener rule for HTTP Path pattern is /this-no-work/*, it worked as expected..
when default endpoin is created in my case it uses this pattern
https://{api_id}.execute-api.{region}.amazonaws.com/
an answer might be: Disable the default endpoint for an HTTP API
more details here
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-disable-default-endpoint.html

AWS API Gateway ERR_CONTENT_DECODING_FAILED in browser

In my use case, API Gateway serves as an HTTP proxy, using default settings following official tutorial.
It's tested working in test console or via curl. But if I access the link in browser or make an AJAX call, I'll get ERR_CONTENT_DECODING_FAILED.
It seems that API Gateway corrupt the content. Related issue.
Is there a way to forbid API Gateway changing my content? I set Content Handling to passthrough, but clearly it's changing my content.
Add a static integration request header Accept-Encoding with value 'identity', so that AWS won't tamper your request.

Setting CORS via API Gateway for Serverless Architecture Model Proxy Endpoint

I am working on a C#/.Net serverless application using the AWS Visual Studio Toolkit, and I am having a bit of trouble figuring out what I am missing as far as CORS configuration. I based my project off of the ASP.Net example included with the toolkit, which configured API Gateway to have a single API endpoint that works as a proxy into the ASP.Net Web API framework.
In testing this application in chrome (serving a local node project) I am getting No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
I know this means I have to configure CORS on the API Gateway endpoint, but I seem to be missing something. I use the actions dropdown to enable CORS as such...
But I get some errors and the problem persists.
I used a chrome extension to disable CORS (temporarily) and have confirmed that the API endpoint works normally without CORS.
So what am I missing here? The examples of setting CORS online don't usually have instructions of a catch-all endpoint like this is set up to use, and even breaking GET into its own method didn't seem to help.
As an additional question, if there is some CORS configuration I am missing, is there a good way to get it integrated into the serverless.template file or some other automated deploy step?
It has to do with your ANY proxy method. As stated here: http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
Note
When applying the above instructions to the ANY method in a proxy integration, any applicable CORS headers will not be set. Instead, you rely on the integration back end to return the applicable CORS headers, such as Access-Control-Allow-Origin
So you will have to make your backend API return the appropriate CORS headers.
You need to have the header on your server as well as the api gateway.
See this sample: - The cors header is applied to the static bucket website
https://www.codeproject.com/Articles/1178781/Serverless-Architecture-using-Csharp-and-AWS-Amazo
For the APIs to work properly two things must be done:
1. The options method must be correctly setup - usually done using a mock method on the API gateway.
2. The HTTP method implementations in your code must return the CORS header correctly. There are quite a few articles about this if you search.
For me the problem was Point 1; using the API Gateway 'Enable CORS' button did not work for me when I was developing API-Gateway Lambda integration using .NET Core. I also didn't find a way to add creation of the options method in the serverless.template file.
Here's another way to do it; after publishing the lambdas from CLI or VisualStudio, fire a PUT request on the API endpoint and pass a swagger definition which contains the options method defs and ensure you set the query param mode=merge. You can use PostMan to do this.
or
You use a DotNet utility which does the same thing explained here:
http://sbytestream.pythonanywhere.com/blog/Enabling-APIGateway-CORS
The source code is available on GitHub too.

Can you statically set a Header and it's value when setting up an HTTP Proxy using AWS Api Gateway endpoint?

I am creating an http proxy using AWS Api Gateway. I would like to hard code some of the headers and their values to be forwarded as part of the request. I thought this might be possible in the 'Integration Request' portion of the proxy setup, but I can't seem to figure it out.
I'm trying to pass an Authorization header with an oauth key. I don't want to share this key with clients that have access to this service, since I will only provide a subset of access to users of this specific endpoint.
In the Integration Request, you can configure a static header value to be sent to the integration endpoint by putting the value inside of single quotes, e.g. 'my_static_header_value'.
Is it a problem to put those hardcoded headers in the request body ? It not, you could just use a template (in the integration request screen) :
{
"hardcoded_header": "$input.params('hardcoded_header')"
}
Hope this helps.