Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added json override option to response body #1621

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nmaison88
Copy link

Description

added an option for allowing json objects in the api response body, reason is Aws allows this functionality. ApiGateway doesnt restrict to only string anymore.

Motivation and Context

How Has This Been Tested?

without the allowJsonInBody nothing changes, you still receive the

errorMessage: "According to the API Gateway specs, the body content must be stringified. Check your Lambda response and make sure you are invoking JSON.stringify(YOUR_CONTENT) on your body object",

by adding the option allowJsonInBody: true in serverless.yml under serverless-offline you can now pass json objects in the response body without the need to JSON.stringify() the contents.

following the instructions on the contributing.md doc i added the custom plugin into my serverless project and then tested without the newly created option allowJsonInBody and the error remains the same, then adding in the option allowJsonInBody i now see the api response as aws does.

tests were manual the code change is a boolean check for allowJsonInBody and if its true we do not throw the error but give the respone.
all existing tests passed locally.

Screenshots (if appropriate):

@nmaison88
Copy link
Author

aws allows straight json objects as its body, when implementing serverless offline we quickly realized the limitation is only within serverless-olffline, i found this has been called out on SO for a bit
https://stackoverflow.com/questions/52406234/serverless-offline-response-issue-while-sending-json-response-in-lambda-function

this is a lightweight fix to keep existing behavior but allow overriding the forced stringify.

@dnalborczyk
Copy link
Collaborator

dnalborczyk commented Dec 2, 2022

thank you for the PR @nmaison88

I might be mistaken, but is it possible that this is only supported with the httpApi, but not with the http (rest Api)?

anyhow, if this the behavior of AWS now, I think we should fix it without the use of a flag?

@nmaison88
Copy link
Author

Hey @dnalborczyk yes this is the behaviour now, perhaps ditching the flag is best, and you may be right, i am using httpApi in my implementation. but i do know for the http (rest Api) a method in which you can still send as json like so JSON.parse(JSON.stringifty(data))

@dnalborczyk
Copy link
Collaborator

@nmaison88 I assume it's this what you are referring to: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html ?

Lambda function response for format 2.0
With the 2.0 format version, API Gateway can infer the response format for you. API Gateway makes the following assumptions if your Lambda function returns valid JSON and doesn't return a statusCode:

isBase64Encoded is false.

statusCode is 200.

content-type is application/json.

body is the function's response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants