Reputation: 1562
I'm having an architecture that looks like that on AWS, if it matters to the issue: Lambda function - API Gateway
I'm testing my API with postman by calling my API with a raw body of application/json type.
But in my lambda, the body looks like this
body: '{
\n\t"name": "Coinche",
\n\t"description": "Un jeu intéressant à plusieurs",
\n\t"rules": "Gagner",
\n\t"origin": "France"\n
}'
which gives me an error, obviously.
So what's the catch here? Doesn't the application/json takes care of sending a json? Should I translate the string back to json inside lambda function?
Upvotes: 2
Views: 5265
Reputation: 147
I had the exact same experience but in a different environment. Under the same server program from desktop windows 10 and mac, postman with windows 10 worked and the one with mac didn't work like yours.
The key "Content-Type" in Headers (refer to the below image) were both unchecked, but once I checked it on mac, it just became normal.
Upvotes: 0
Reputation: 1670
This is not exactly an answer to the question, but for me, none of this resolved the issues of getting \n\t
added to my JSON. JSON.parse and JSON.stringify all failed with this and I could not get past the errors being thrown.
I switched from using Postman to Insomnia and problem went away. I also noticed it uses end-to-end encryption so I'm not trying to bother with variables in the same way for my keys etc..
I just have a JSON file with all my variables to re-use in Insomnia. Works pretty nicely so far.
I'm not trying to sell anything here, it is just that it took me a while to even figure out what was going on and that the issue was coming from Postman, so it seemed worth sharing.
Upvotes: 1
Reputation: 168
You may require to add Content-Type: application/json on API Gateway Integration Request body template mapping like this:
Upvotes: 2