My resource /api has a method POST which proxies the body to Kinesis Firehose (and then to ES). At the same time I want it to trigger a Lambda function.
I tried adding an additional method ANY to trigger the Lambda function but API Gateway seems to preference the POST handler.
I am aware that I can trigger Lambda on POST and submit from the Lambda function to Firehose but I'd prefer having those two independent from each other.
API Gateway doesn't fork a request into multiple concurrent actions. An ANY method means "any method without a defined method." Since you also have POST defined, any POST will not see the ANY.
To do what you appear to be attempting -- execute a Lambda function and make a call to the Kinesis API, you will need to write an initial Lambda function that serves as a wrapper and performs both actions -- send a request to Kinesis and send a request to Lambda (to invoke the other Lambda function) -- asynchronously if the business logic permits it -- then marshal the results into a single coherent response that meets your needs.
This first Lambda function does not need to be in the same language as the second, so for example, if the existing Lambda function is in Java, the wrapper function could be written in Node, with no negative performance implications, since it executes independently on the other side of the Lambda API.
Related
Say I have an endpoint for creating an object that takes time to complete which has the following URL structure: /api/v1/objects.
Business rules dictate that API consumers can either call this endpoint synchronously or asynchronously in the server. The result of this call in the end is the creation of the same object, but response upon submission of the endpoint is different between the two depending on whether it is called synchronously or asynchronously (i.e. if the call is made asynchronously, a consumer may get an identifier with no guarantee if the object will be created or not, while calling the endpoint synchronously will always create the object and return it in the response.)
Right now I have this structure for distinguishing between the synchronous and asynchronous API calls:
POST /api/v1/objects - for creating the object synchronously.
POST /api/v1/objects?async=true - for creating the object
asynchronously.
Is this approach correct and conforms to RESTFul principles?
If you look at the RFC for HTTP (see https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1 ) you can see the Expect header, which basically defines what behaviour the client is expecting from the server.
Considering you can have different 20* responses (200, 201, 202, 204), you can use this to determine whether it should be async or not.
A quick Google search comes up with this example (which I copy and paste here for future reference):
A client may request the server to modify its asynchronous behavior
with the following “Expect” headers:
“Expect: 200-ok/201-created/204-no-content” disables all asynchronous
functionality. The server may return a “417 Expectation Failed” if it
is not willing to wait for an operation to complete.
“Expect: 202-accepted” explicitly request an asynchronous response. The server
may return a “417 Expectation Failed” if it is not willing to perform
the request asynchronously. If no expectation is provided, client must
be prepared to accept a 202 Accepted status for any request other than
GET.
I have an AppSync PIPELINE composed of an auth-service + business-service.
I have implemented RBAC in auth-service, so based on the operation and the role that the user has, it allows or dennies the execution of the bussiness-service.
I need to map the GraphQL Mutation or Query field (method called from the client) to the operation (for example if the user try to do the Mutation: addUser, this is the operation).
Is it possible to get the method executed by the client in the resolver at run time? (for example addUser, deletePost). In order to not have to implement a different auth-service for each of the Queries and Mutations?
Similar scenario, here's what I'm doing:
Before Mapping - Save identity/claims from Cognito etc. to the stash.
Function Request - Check stash, if unauthorized $util.error, else
store the operation name and operand details in the stash before
continuing.
Function Response - Perform any other filtering or ownership checks
on the response, $util.error/early return if unauthorized.
After Mapping - Final transformation of the response or passthrough.
Basically I felt that exposing deep knowledge about an Entity to a generic pipeline auth function was a bad idea, I was more comfortable with an entity's resolver function being aware of what is allowed/disallowed.
I'm following some Azure Function tutorials on creating a REST API, this all seems straight forward. However I'm struggling to understand how I should deal with the different verbs.
Is the recommended practice to create a separate Azure Function for each verb? And then also separate functions for each variation of routing for each verb, so a e.g. a separete function for each of:
products/{productid} (GET)
products (GET, returns list)
products/me (GET returns a list of products belonging to the user making the request)
It seems to me I'm going to end up with a lot of Azure functions here. In the WebAPI approach I would have put all these in a single controller and the attribute routing would have taken care of the rest.
Is there another way to achieve this with Azure function?
You can use Azure Function Proxies to setup routing for HTTP verbs and parameters and then pass the call down to a single function. Creating a function per each verb/parameter combination seems to be an overkill.
Of course, if processing logic is completely different e.g. for GET vs POST, it makes sense to put those into separate functions. So, in the end it's your call, but you have tools for both scenarios.
I deployed a GET method in AWS API Gateway which is then integrated with AWS Step Functions as backend.
The Problem is the integration with Step Functions only allowed through Http "Post" method.
That means I set input to Step Functions but can not get the output of the Step Functions.
Does anyone have idea to solve this ? Thank a lot
Well, you could do it the same way I did, by using a Lambda function to invoke the step function and return it's result from within the Lambda function, if it runs in less than 30 seconds.
It would look like this API Gateway <--> Lambda <--> Step function
See https://stackoverflow.com/a/41773504/7243001
We want to use the AWS API Gateway as the central entry point to our application and let a custom authorizer validate the provided JWT.
Thereby we have several private claims that we would like extract and then pass on to subsequent services (i.e. optimally the lambda function should return these extracted parameters and could then be mapped within the API gateway).
My question is now:
Is that possible? So far I only found auth policies that were made up of two objects: the principalId and the policyDocument.
You can't pass back any additional data at the moment, but we have this on the backlog to do along with some other improvements to Lambda authorizers that I'm sure you will find useful. No ETA for those improvements at the moment.
Edit: additional context for the authorizer response has been released. Public docs are delayed, but see my answer here: https://stackoverflow.com/a/40644554/5679071
You can use authorizers now to do so. I guess what you mean is you have a payload to extract from the JWT. You can do so with Lambda Authorizer (or custom authorizer for API Gateway's version 1 (REST API)). You can return extra info in the authorizer's response's context. It will become the underlying lambda functions' event.requestContext.authorizer. More details in my post https://shaowang.hashnode.dev/aws-lambda-functions-with-lambda-authorizer if you want to copy things in event.requestContext.authorizer into event directly with a helper decorator. Happy to take questions.