I am using Node.js for AWS Lambda + API Gateway APIs.
I have multiple Lambda functions and each giving different response formats as it integrated multiple third party SDKs like Stripe/DynamoDB and all.
Is there any way to get common response for all the functions like below?
{
"success" : true,
"data" : { RESPONSEFROMLAMBDA },
"messages" : null,
"code" : 200,
"description" : "OK"
}
The third-party services your Lambda functions are using shouldn't have any bearing on the response format. You just need to update all the API Gateway endpoints to use a mapping template with this format.
Related
I'm just doing the preparation for an integration with EasyPost's Shipping API, which will be server side C#, but we always build a PostMan collection for new integrations, so that we can test data separately from the application if there's an issue.
While I do love the fact that EP provide C# libraries and examples, I'm struggling to find anything that just gives me a list of required headers and the raw JSON format for the body of any requests. It feels a bit like they're just being a little too helpful.
I'll be looking at the Orders endpoint probably.
I've got an account, I've checked all their documentation and searched the internet but haven't found anything so I'm hoping I'm not the first developer to want to use a client application for testing outside my code.
Update:
EasyPost now does have a public workspace https://www.postman.com/easypost-api
with at least 1 public collection
The curl examples are basically the same as json:
For the Address creation example:
-d "address[street1]=417 MONTGOMERY ST"
is the equivalent of
{ "address": { "street1": "417 MONTGOMERY ST" } }
(you might have to escape some characters to be valid json).
Check out How to stimulate cURL request to a request using postman for postman with HTTP Basic Auth.
EasyPost does not provide a public Postman collection; however, here is an example of a shipment Postman body (raw) that could be used. You can adjust the values, actions, objects, etc to your needs.
Using the following, you shouldn't need to pass any headers. You'll pass your API key under the username field with the Basic Auth authorization type.
{
"shipment": {
"to_address": {
"id": "adr_123..."
},
"from_address": {
"id": "adr_123..."
},
"parcel": {
"id": "prcl_123..."
},
"carrier_accounts": {
"id": "ca_123..."
},
"options": {
"address_validation_level": "0"
}
},
"format": "json",
"controller": "shipments",
"action": "create"
}
I'm trying to ascertain what best practice might be for returning a JSON response for a Restful API call. I've read multiple blog and tutorial articles that offer different opinions.
One approach I've seen proposes that any Restful call return a JSON response that includes both meta data and result data, like the representation shown below:
// response to a GET that returns an array of elements
{
"status": "success",
"count": 2,
"type": "LoadServingEntity",
"results":[ {
"lseId": 2756,
"name":"Georgia Power Co",
"code":"7140",
"websiteHome":"http://www.georgiapower.com/"
}, {
"lseId":1,
"name":"City of Augusta",
"code":"1000",
"websiteHome":null
}]
}
// an response that reports an API error
{
"status":"error",
"count":2,
"type":"Error",
"results":[{
"code":"NotNull",
"message":"An appKey must be supplied",
"objectName":"requestSignature",
"propertyName":"appKey"
}, {
"code":"NotNull",
"message":"An appId must be supplied",
"objectName":"requestSignature",
"propertyName":"appId"
}]
}
Other articles poo-poo this approach. I'm about to start a new API project and I'd like to get feedback from experts about the best approach on this subject.
TIA
Check out http://jsonapi.org/ which provides a recommended specification for building a JSON API. The response should include both the data and metadata
I set up a POST ressource in API Gateway which invokes a Lamdba function, fine.
In the "integration request", for text/plain Content-type, I defined the following mapping :
#set($messageStr = $util.urlEncode($input.body))
{
"message" : "$messageStr"
}
Problem is : whenever I POST data with JSON reserved characters, the integration request mapping thows
{"message": "Could not process payload"}
Example : blablabla will be correctly passed through to lambda, not {blablabla nor a:e ...
This seems like that method urlEncode expects JSON data.
Any idea how to pass whatever body as pure text ?
Thanks
I am making a simple REST API using latest stable version of Lumen. That API is going to be used in mobile applications, and there is one thing I'm not sure about.
What is the best ( secure enough ) way to an authorization? At the moment I am doing a simple POST request to the server url like http://api.example.com/v1/auth with username and password parameters and return a JSON response like
{ "code" : 200, "message" : "OK", "access_token" : string }
or
{ "code" : 401, "message" : "Unauthorized" }
Is JSON response a good solution?
Is it better to return response code within header?
Have you checked this? https://softwareengineering.stackexchange.com/questions/183665/the-best-way-to-implement-authorization-for-a-rest-api
200 and 401 seem the "standard" response to me.
Using the Socrata SODA api for within_polygon an error is thrown stating that it is too complex.
https://www.dallasopendata.com/resource/x9pz-kdq9.json?$where=within_polygon(location,%20%27MULTIPOLYGON%20(((-96.79920%2032.77946,-96.807768%2032.7751,-96.7999%2032.76999,-96.79920%2032.77946)))%27)
{
"code" : "query.execution.queryTooComplex",
"error" : true,
"message" : "Only simple comparison filters are allowed",
"data" : {
"reason" : "validation.complex-filter"
}
}
Here is a working version:
https://data.cityofchicago.org/resource/yama-9had.json?$where=within_polygon(location,%20%27MULTIPOLYGON%20(((-87.63742446899414%2041.871733907393164,-87.64720916748047%2041.8687938398043,-87.6540756225586%2041.86080384272637,-87.64214515686035%2041.85287677909342,-87.63467788696289%2041.859141797891915,-87.62866973876953%2041.86329682898112,-87.63038635253906%2041.86789900978502,-87.64317512512207%2041.86380819876315,-87.64326095581055%2041.86591755588323,-87.63742446899414%2041.871733907393164)))%27)
You're using the old API endpoint, rather than the new one that supports within_polygon(...). You'll want to use this one instead. The query works as expected against that new endpoint:
https://www.dallasopendata.com/resource/5nug-crr9.json?$where=within_polygon(location,%20%27MULTIPOLYGON%20(((-96.79920%2032.77946,-96.807768%2032.7751,-96.7999%2032.76999,-96.79920%2032.77946)))%27)
For more details on the migration process, check out this entry in the API changelog.