I think I hit an AWS API Gateway scenario that doesn't appear to have a solution.
I am trying to create a json POST endpoint to validate an address against a USPS service.
The ultimate request looks like this:
http://production.shippingapis.com/ShippingAPI.dll?API=Verify&XML=<AddressValidateRequest USERID="SECRET"><Address><Address1>101 Foo Lane</Address1></Address2><City>Somewhereville</City><State>CA</State><Zip5>90210</Zip5><Zip4></Zip4></Address></AddressValidateRequest>
The issue I'm having is I need to set the XML query string parameter based on my passed in method body, e.g.:
{
address: "101 Foo Lane",
city: "Somewhereville",
state: "CA",
zip: "90210"
}
It appears in the Integration Request, I can specify the "Mapped from", but I can't access the method body, only the method.request.{"path", "querystring" | "header"}.{param_name}
Also there doesn't appear for me to construct a param_name value in the Method Request setup from the incoming method body.
The XML to JSON response mapping is working great if I provide a hard coded XML query string, so I'm down to just the request mapping.
You can map the body to request parameter using method.request.body.JSONPath_EXPRESSION but you can't construct the request parameter using a template similar to what can be done for integration request body. All the available mappings are documented here - http://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html
Related
I am using postman application to do a SugarCRM POST request, following is the request
https://{site_url}/rest/v11/{module_name}/filter?filter=[{"$is_null"="logoutdttime"}]&fields=name,username,logoutdttime&order_by=date_entered&max_num=10
I am getting the error
{
"error": "invalid_parameter",
"error_message": "Unexpected filter type string."
}
but when I remove the filter, I get the response
https://{site_url}/rest/v11/{module_name}/filter?fields=name,username,logoutdttime&order_by=date_entered&max_num=10
what am I doing wrong
The filter is defined as array via the key and in an assoc array style rather than json. That's weird, but that's how it works in Sugar Query-String params.
Try:
https://{site_url}/rest/v11/{module_name}/filter?filter[0][$is_null]=logoutdttime&fields=name,username,logoutdttime&order_by=date_entered&max_num=10
Alternatively you can use the POST /filter endpoint instead of GET.
Then you can pass all params in the request body as json.
PS: Also are you sure you mean $is_null and not $empty?
try this:
filter[0][name][$starts]=any text
Document:
https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_12.0/Integration/Web_Services/REST_API/Endpoints/Accountsrecordlinklink_namefilter_GET/
We have stock website and we help buyers connect with the sellers. We are creating API to let buyers push their contact details and get back the seller details. This is transaction and get logged in our database. We have created following API:
The request is POST, the URL looks like:
/api/leads
The request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123"
}
The response looks like:
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park"
}
We have a new requirement, i.e. we need to send back PDF URL (instead of "sellermobile" & "selleraddress"). This PDF URL would contain the seller details in case it comes from one of our client.
We have modified the same API, now the request body looks like:
{
"buyermobile": "9999999999",
"stockid": "123",
"ispdf": true
}
The response looks like:
{
"sellerdetailspdf" : "https://example.com/sellerdetails-1.pdf",
}
Is it RESTFUL to do this? OR we should create separate API for getting response as PDF?
I wouldn't approach it this way. What happens when you need to add XLS? Do you add "isxls" to the request too?
Things I'd consider:
Use a mime type for content negotiation. Post the same request, and specify in the Accept header what you expect back - JSON, PDF, etc. You're then actually getting the report instead of a link to the report, which may or may not be better.
- or -
Include a link in the typical lead response.
{
"sellermobile" : "8888888888",
"selleraddress": "123 avenue park",
"_links": {
"seller-details-pdf": "https://example.com/sellerdetails-1.pdf"
}
}
- or -
Support a query parameter that specifies the type in the response.
- or -
Have a single property that specifies the type in the response, rather than a boolean. Much cleaner to extend when you add new response types.
The first two options have the bonus that you don't require clients to handle multiple response types to a single request. That's not forbidden by any spec, but it's annoying for clients. Try not to annoy the people who you want to pay you. :)
Again the implementation looks good to me, however you could potentially look at breaking the return of the PDF URL to another endpoint maybe something like api/lead/pdf that way your request body is the same for api/lead and all subsequent endpoints under /lead. Allowing your routes and other code to handle small portioned tasks instead of having a route that handles multiple flags and multiple code routes.
That looks good to me - the same type of input should give the same type of response but in your case you have two different types of input - one with the "ispdf" flag and one without. So it's consistent to responds with two different types of response, one with the PDF link and one without.
That's still something you'll want to document but basically it's a correct implementation.
I'm trying to use a service of DocuSign API in an abap project. I want to send a document to a specific email so it can be signed. But im getting the following error:
"errorCode": "INVALID_REQUEST_PARAMETER",## "message": "The request contained at least one invalid parameter. Query parameter 'from_date' must be set to a valid DateTime, or 'envelope_ids' or 'transaction_ids' must be specified.
I tried the following:
CALL METHOD cl_http_client=>create_by_url
EXPORTING
url = l_url (https://demo.docusign.net/restapi/v2/accounts/XXXXXX')
proxy_host = co_proxy_host
proxy_service = co_proxy_service
IMPORTING
client = lo_http_client
lo_http_client->request->set_method( method = 'POST').
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'Accept'
value = 'application/json'.
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'X-DocuSign-Authentication'
value = get_auth_header( ). (json auth header)
CALL METHOD lo_http_client->request->set_cdata
EXPORTING
data = create_body( ).
This is my body:
CONCATENATE
`{`
`"emailSubject": "DocuSign REST API Quickstart Sample",`
`"emailBlurb": "Shows how to create and send an envelope from a document.",`
`"recipients": {`
`"signers": [{`
`"email": "test#email",`
`"name": "test",`
`"recipientId": "1",`
`"routingOrder": "1"`
`}]`
`},`
`"documents": [{`
`"documentId": "1",`
`"name": "test.pdf",`
`"documentBase64":` `"` l_encoded_doc `"`
`}],`
`"status": "sent"`
`}` INTO re_data.
The api request to get the Baseurl is working fine. (I know the error is quite specific what the problem is, but i cant find any sources on the docusign api documentation that one of the mentioned parameters should be added to the request)
Thank you in regards
The error message seems to indicate that you're Posting to an endpoint that requires certain query string parameters -- but you're not specifying them as expected in the query string. I'd suggest you check the DocuSign API documentation for the operation you are using, to determine what query string parameters it requires, and then ensure that you're including those parameters in your request URL.
If you can't figure this out using the documentation, then I'd suggest that you update your post to clarify exactly what URL (endpoint) you are using for the request, including any querystring parameters you're specifying in the URL. You can put fake values for things like Account ID, of course -- we just need to see the endpoint you are calling, and what qs params you're sending.
To create an envelope, use
https://demo.docusign.net/restapi/v2/accounts/XXXXXX/envelopes
instead of
https://demo.docusign.net/restapi/v2/accounts/XXXXXX
Thank you for all the answers, i found the mistake. Creating the request wasn´t the problem. I was using the wrong "sending"-method -_-.
now its working :)
lo_rest_client->post( EXPORTING io_entity = lo_request_entity ).
I've heard that in REST world, POST is recommended to create an entry, while PUT is recommended to update an entry.
First, I'd like a confirmation of this statement.
Then, using this assumptions, let's say I have a #POST method to create a user and a #PUT method to update a user (with a #QueryParam to pass the user ID).
What is the correct way to pass parameters to POST and PUT?
Is #FormParam appropriate for #PUT? Or should I pass a JSON in the body?
Should I pass parameters the same way for both #POST and #PUT or a different way?
Or should I use POST for both?
Edit: This question initially showed an example that did not work for me, but it was because my testing tool was doing it wrong. It works with POSTMAN now.
Yes, with REST, you typically use the following:
The method POST of the element list resource to add an element
The method PUT of the element resource to completely update an element
The method PATCH of the element resource to partially update an element
Since what you must send corresponds to the state of the resource, you have to provide it within the request body.
The two bodies (for adding and updating) is similar but there are some differences. For example, if you expect the RESTful service to autogenerate some fields, you don't have to provide corresponding ones.
Here are sample requests:
POST /contacts
{
"lastName": "my last name",
"firstName": "my first name",
}
(corresponding response status code: 201 - Created)
PUT /contacts/contactid
{
"lastName": "my last name",
"firstName": "my first name",
}
(corresponding response status code: 204 - No content)
You can notice that JSON isn't the only format you can use. XML, YAML, and so on could also be used.
I think that the following link could give you some hints:
Designing a Web API - https://templth.wordpress.com/2014/12/15/designing-a-web-api/
Hope it helps you,
Thierry
Currently I have a resource defined in Angular like this:
Users: $resource(APIBASEROUTE +'/users/:_id', {_id: '#_id'})
When I call for a user with this code:
$scope.user = ayApi.Users.get({id:$routeParams.userId});
The request is sent as a query parameter like this:
http://localhost:3000/api/v1/users?id=526eff826a6100fb22000000
However it needs to hit the REST server like this:
http://localhost:3000/api/v1/users/526eff826a6100fb22000000
How do I make Angular do it this way?
I guess that the problem is in incosistency of the parameters names.
in definition you have: {_id:'#_id'}), it should be the {id...
Or in your call it should be with underscore
$scope.user = ayApi.Users.get({_id:$routeParams.userId});
Any other parameter (not mapped in the resource definition) is treated as a query string param. That's why angular decided to append your id as a query string part. It is not _id