WSO2 API Manager "error": "no response from server" - wso2

I have published API in WSO2 using swagger JSON. After publish I am trying to call rest api using swagger in APP Console. It says
Response Body no content
Response Code 0
Response Headers {
"error": "no response from server"
}
There is no any error on server which will help me to understand problem.
Here is the request URL which I am using in local server : https://192.168.1.118:8243/api/2.0/questions/1/answers?start=1&end=1&fields=answerId%2CanswerDescription%2CcreateDate

In my API there are some custom header parameter. Because of this custom header parameter it was not working. I have added custom header parameter in api-manager.xml file.
<Access-Control-Allow-Headers>authorization,Access-Control-Allow-Origin,Content-Type,loggedInUserId,accessToken,clientToken</Access-Control-Allow-Headers>

I have faced a similar issue. I have edited the URL(from apicreator login) after it was published for first time and published it again. But the changes were never reflected. WSO2 was pointing to the old URL. Check the logs for error at "WSO2 HOME\repository\logs\wso2-apigw-errors" . Create another version and publish again and it should work.

The error is real, but misleading. In most likelihood, you've set the spec so that it returns a specific content type (say, application/json) but you actually return plain text (like a string or a number). swagger-ui expects it to be a JSON, tries to parse it and fails, giving you the wrong error message. However, it does mean your spec does not match what your API actually does.

Related

How to read request's body in WSO2 ESB?

Hi everyone I am new using WSO2 ESB, here is the issue I made a integration project to learn but I have not been able to read the body of my request when I try I see this warning "Json Payload is empty"
enter image description here
Here is how I am trying to read the body <filter regex="[1-9]" source="json-eval($.test)">
enter image description here
And finally here is my request, I already set the header application/json
enter image description here
If anyone could help me, I would be very grateful. Thanks in advance
The request needs to be a POST to see the payload hit the ESB.
With GET it will just do a GET request without it.
Technically you can do GET with body but it's not a very common scenario.[1]
[1]https://docs.wso2.com/display/EI611/Unusual+Scenarios+for+HTTP+Methods+in+REST#UnusualScenariosforHTTPMethodsinREST-UsingGETwithaBody
That is because the GET method in wso2 does not allow the body payload. You can read in wso2 documentation:
Typically, a GET request does not contain a body, and the ESB profile does not support these types of requests. When it receives a GET request that contains a body, it drops the message body (...)
From doc: Using GET with a Body
Additional it is not good practice to do that, refer to this question: HTTP GET with request body
So you should use POST request.

How to set the api version being called in API Gateway when integrating with AWS Service CloudWatch?

I get the following error message when calling actions for CloudWatch in API Gateway.
"Error": {
"Code": "InvalidAction",
"Message": "Could not find operation DescribeAlarms for version 2009-05-15",
"Type": "Sender"
}
I've been using DescribeAlarms for testing. My setup is as follows.
Integration Type = AWS Service
AWS Service = CloudWatch
HTTP method = POST
Action = DescribeAlarms
The error references the API Version 2009-05-15, which only has ListMetrics and GetMetricStatistics according to it's documentation on page 54. ListMetrics does indeed work as expected with my setup.
The current version is 2010-08-01 but I don't see anyway to reference that in API Gateway. In an example of a POST request in the documentation it shows a header labeled x-amz-target with a value of GraniteServiceVersion20100801.API_Name.
My interpretation is I can put Name = x-amz-target and value 'GraniteServiceVersion20100801.DescribeAlarms' in my http header for the Integration Request in API Gateway.
This doesn't change the response and gives the same error message.
I also used the --debug in CLI when calling describe-alarms, and in the body it shows...
"body": {
"Action":"DescribeAlarms",
"Version":"2010-08-01"
}
So I also set http headers to include Content-Type with a value of 'application/x-amz-json-1.1' and then put in
{
"Action":"DescribeAlarms",
"Version":"2010-08-01"
}
but nothing changed with that either.
Any help or guidance would be greatly appreciated.
Under Method Integration -> URL Query String Parameters
I added Version as the Name and '2010-08-01' under Mapped From.
All actions are now working as expected.
I'm trying to PutMetrics directly from Api Gateway -> Cloudwatch using PutMetricData, Version in the query string params didn't work for me.
These 3 HTTP headers in the Integration Request solved it for me:
Content-Type 'application/json'
X-Amz-Target 'GraniteServiceVersion20100801.PutMetricData'
Content-Encoding 'amz-1.0'

parameter postman-token couldn't find in SoapUI request

I am getting familiar with both Postman and SoapUI. I already have a doubt. When I make a GET call with from the postman-echo service, I get slightly different responses shown to me in Postman and in SoapUI.
In particular, in Postman I get
"postman-token": "1ef2b330-3a46-4681-a304-d72f020cb194"
This field-value pair is not shown by SoapUI.
Can anyone explain me the apparent difference?
The parameter postman-token being added while you send a request from Postman. So, it's a custom parameter, you cannot expect it to be present with other tools.
If you check Postman doc of General settings They have explained what is that param is for:
This is primarily used to bypass a bug in Chrome. If an XmlHttpRequest
is pending and another request is sent with the same parameters then
Chrome returns the same response for both of them. Sending a random
token avoids this issue. This can also help you distinguish between
request on the server side.
You can disable it from Postman settings. Goto Settings > General > Send Postman Token header.

Postman inconsistent behaviour with cURL request

I have the following API downloaded in JSON from Swagger Editor:
PUT http://10.37.64.243/m2m/fim/items/fim:device:manager/operations/getAllDeviceTypes?exclude={{exclude}}
with exclude being an environment variable set as : href,metadata,name,arguments
Nominal use requires basic authentication, in this case it works and I get a JSON body with expected result. It properly works in Postman (so I think my import is correct)
If no authentication is provided:
in Swagger Editor : nominal behaviour, request is rejected with error code 401
in Postman : UNEXPECTED behaviour, I end up with status code 200 and it returns a response body identical to the one that I get when authenticated
if I generate the cURL code snippet from Postman and launch it out of Postman: nominal behaviour, I get the same error as the one I get in Swagger Editor (the one expected)
Why do Postman behave differently from the cURL request ??
I probably do something wrong, but I can't figure out what
Thanks for any help
Alexandre
I finally found out that the server returns a cookie that holds authentication validation. So after a valid authentication, whatever the request (with or without authentication) it will be considered as authentified.
Unfortunately, the only way to overcome that problem is to remove the cookie by hand through the "Manage cookies" window. Postman does not implement a function that erase it (even through the pm.cookies and pm.cookies.clear() function).
Postman developpers are aware of that, but there's no scheduling for this feature ...
EDIT: the feature is followed here https://github.com/postmanlabs/postman-app-support/issues/3312

Problem with Posting JSON object with WSRequest

I want Play to call a webservice. The webservice accepts application/json and returns this as well. With the following code I'm trying to achieve this. (Note, the headers.put(xxx) are added later in an effort to solve the problem).
WSRequest request = WS.url(targetURL);
request.body = new Gson().toJson(user);
request.headers.put("Content-type","application/json");
request.headers.put("Accept","application/json");
request.post();
The strange thing is that my JBOSS server replies: "Cannot consume content type". If I use my 'Simple REST client' plugin in my Chrome browser, and provide the entire JSON Body GSon created and add the content-type header, I get a valid response. Is this not the way to send JSON to the server? Or am I missing some fundamental piece here?
While checking the API documentation on the WSRequest class i noticed the field mime-type
By setting it as follows JBOSS (resteasy) accepted my request succesfully.
request.mimeType = "application/json";