i have api gateway with 3 simple backends:
2 basic api routes (/plus and /minus) backed by lambda functions
1 direct sqs queue (/sqs_send)
It means i can send via api call directly to my sqs queue.
2 lambda backend functions take 2 params 'a,b' from api call and add,subtract and show output.
https://86bwtlv5ya.execute-api.us-east-1.amazonaws.com/minus?a=10&b=20 # prints -10 in browser
https://86bwtlv5ya.execute-api.us-east-1.amazonaws.com/plus?a=10&b=20 # prints 30 in browser
The 3rd function is tricky for me. Via postman i managed to send directly to sqs like this via put request. Notice how i have to select "body" "raw" then input message. I did check the sqs queue - the msg from postman is there.
My question - what to type into my api gateway endpoint to send msg directly to sqs? Without using postman?
https://86bwtlv5ya.execute-api.us-east-1.amazonaws.com/sqs_send?mesagebody # what to type after sqs_send?
This did not work - returns {"message":"Not Found"}
https://86bwtlv5ya.execute-api.us-east-1.amazonaws.com/sqs_send?
Action=SendMessage&
MessageBody=This+is+a+test+message
Is it possible, my sqs_send api route does not work with parameters, because it is designed to only work with "messagebody" as per my settings? "Message attributes" is empty?
If I understood correctly, you want to call your API gateway endpoints by directly entering the URL into your browser's address bar.
Short answer:
Unfortunately you can't do this with your 3rd endpoint /sqs_send, because it is a PUT endpoint which the browser cannot call directly through the address bar.
Details:
Browsers usually support only HTTP GET and POST methods directly, through form submissions (which in turn is an HTML limitation, where form submissions only support these two methods). In GET method, parameters are appended to the end of the URL in the pattern example.com/?name1=value1&name2=value2. In POST method, parameters are included in the body of the request, so they're not visible in the URL itself. This means that you can only call GET endpoints by directly typing into the address bar of your browser. Your /plus and /minus are likely GET endpoints. POST endpoints must be called via HTML form submissions to include your parameters.
For calling other methods like PUT and DELETE (in addition to GET and POST), you will have to use XMLHttpRequest or the Fetch API, or some frontend framework method built around them. As your Postman screenshot shows, your third endpoint /sqs_send is a PUT, so you can't call it directly by entering the URL into the browser's address bar. If you must call it this way, you will have to convert your endpoint to a GET so that you can send your parameters via URL parameters.
Related
I am trying to connect a Slack slash-command to an AWS Lambda (through the AWS API Gateway).
I was able to adapt the Hello, World blueprint (written in Python) in the Lambda tutorial section. I set up an API gateway as a trigger, then had Slack POST the slash-command to the API endpoint. I had to manually decode the base64 body, then use parse_qs to convert the query string-like POST body into a dictionary, where I could then access it just fine.
My real Lambda code is currently in Java, but I've started with the java-basic sample app from the Developers Guide. I built the app, uploaded the jar, and confirmed the correct handler was being called. I set up another API gateway and pointed a different Slack slash-command at the new endpoin. It fails.
The log looks like:
java.lang.RuntimeException: An error occurred during JSON parsing
Caused by: java.io.UncheckedIOException: com.amazonaws.lambda.thirdparty.com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
at [Source: (ByteArrayInputStream); line: 1, column: 1]
I'm guessing this means Slack is sending the same query string-like argument in the POST body, and for some reason, something is expecting JSON input, not just text. I don't understand why the Python handler was okay with building up an event dictionary and making the Lambda decode the POST body, whereas the Java handler is never getting called, but is dying before that when attempting to deserialize the POST body, thinking it's JSON.
Both Lambdas and API gateways were set up with the usual defaults, AFAICT.
I solved the problem by switching to using the HandlerStream example. I can then get the "body" from the event, Base64.decodeBase64 it, then unpack the form parameters with UriParameterMap.parse.
I then process the incoming text that came from the Slack slash command and then return a string of JSON that Slack expects.
My requirement is I will expose the ESB integration implementation as a REST API.
1) In the implementation part whenever they will call This ESB API it has to route based on content in the post request sent to ESB(this can be achieved by content based routing pattern ).
2) But on the Endpoint side Which is to be called by the ESB while routing based on content may vary means, if today there is 2 end point to call tomorrow it may rise to 5 like that how to apply changes are is there any solution. So, how to achieve this dynamic integration.
I have 4 ways to achieve this integration pattern.
1) Deploy files in the registry which has the endpoint in it and having the file name which is same as the content name(regex) sent in the payload for routing. Then by storing that name in property mediator and use concat function to read that file in another property mediator, and by pattern matching read the endpoint. Thus you can use that endpoint and achieve the dynamic content based routing.
2) Have separate sequence each one to call one endpoint and have the same name as the content name. The main sequence will call the sequence based on the content.
3)Store the content on which to be routed and endpoint in the RDBMS database then use DB lookup mediator to retrieve the endpoint based on this you can route.
4) I think this is best and suitable for integration scenario where tomorrow the endpoint may change( that is when the number of the endpoint is not fixed ) and each endpoint wants a different transformation of the payload(I mean XML to json or JSON to XML etc..).
First, use one API and store the content in property mediator and use that mediator to call another API which has the implementation to call the endpoint.
For example, if the content based on which routing has to happen has the payload like this
{ "content":"c1" }
Store the content in property mediator using name uri.var.address. Then create another API's which will have the implementation to call endpoint(For each endpoint create separate API's) and URI-Template of the API's should have content stored in the property mediator(same as payload request). While using send mediator to call these ENDPOINT implemented API's use http request having url of the API with /{uri.var.address} because to match the URI-template details.
I am using multiple webservices API from multiple clients.
I can see the URL in the network tab in the browser inspect. i don't want to expose the URL.
Is there any way to encode the URL to unread format?
From client side, no way. Maybe use a gateway url which does server-side call to "wanna be hidden" url and returns its result to the client ? But it wouldn't change the fact the output would be the same.
if you want to hide an url call from the client, don't do it client-side.
You have to change your design , essentially you need to put a proxy layer in between your client and actual API where the proxy can take a generic input with the encrypted url as the parameter something like
/Apiproxy/{encrypted url}
And the proxy can decrypt it and sent it to the actual u. You do have the complexity of managing the encryption key as well with this approach.
But why do you need this thing ?
Can the API Gateway evaluate requests and route or return errors (not 200 statuses) on specific parameters?
What I want to achieve here is to NOT have millions of requests hitting our backend API since we already know (by evaluating the parameters) that we are not interested in returning responses on all requests but only a few percent.
I gave set up an API Proxy in the API Gateway with a complete set of requests, responses and backend.
The proxy is fully operational and up and running with throttling etc. What I would like is for the API Gateway to evaluate the requests querystring and depending on the values of certain parameters take different actions?
Let's say the complete URL and querystring is:
https://abc123.execute-api.eu-central-1.amazonaws.com/prod?param1=a¶m2=b¶m3=c
Now depending on the values of param1, param2 and param3 I might want to:
Forward the request to my actual API and return a response back to the client.
Drop the request OR return an empty (or templated) response with a specific HTTP-status (404, 503 etc - exact value not that important).
Is this achievable with the API Gateway or do I need to actually set up a host with a reverse proxy and let that handle this logic?
Request parameter and model validation has been a longstanding feature request and we are actively working on it. We'll update this post with more details when the feature has launched.
Update: Request parameter and body validation is now available as of early April 2017. see more details on this blog post.
I want to use API Gateway as a caching proxy for an HTTP server, which in turn uses jsonapi-resources to define the API.
The issue is that jsonapi-resources requires query string parameters of the form ?page[number]=10&page[size]=10 to paginate results. However, if I try to add page[number] to URL Query String Parameters on a Method Request page, I receive the following error:
I've also tried to percent-encode the name as page%5Bnumber%5D without any success; the parameter is still filtered out.
Is there a way to make it work?
If you encode the [ by %5B, API Gateway doesn't allow % in the parameter name.
Currently, AWS API Gateway only supports the parameter name matches ^[a-zA-Z0-9._$-]+$
Does page.number work for you?