I am using jquery ajax to pass json rpc request to remote server. Here is my json string:
{"jsonrpc":"2.0","method":"merchant_check","params":{"hostID":150999,"orderID":107,"amount":"7777","currency":"051","mid":15001038,"tid":15531038,"mtpass":"12345","trxnDetails":""},"id":107}
I am getting this error:
{"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid JSON-RPC 2.0 request error (-32600)"}}
What am I doing wrong? Thanks for help.
It may be the JSON liberary the service is using. Try the following:
Put spaces between the end of a key string+colon amd tje value, "key": "value" vs "key":"value"
Try putting the request id as a string, "id": "1" vs "id": 1
I don't know how well ist was coded, the service, but if you have malformed parameters, it may give you the-32600 error, instead of -32602. So what kind of currency are you using that requires no decimal and gets sent as string? What is a "mid", an integer?
Your request object looks good, it think it's what the service is expecting and calling good or bad request object.
I had the same problem using json-rpc net. The problem was caused by the content-type header. By default it was being set to application/x-www-form-urlencoded by my browser and it generated that error. Setting it to application/json fixed my issue.
Related
I can not figure out why I get this error:
"Failed to parse request body as JSON resource. Error was: Failed to parse JSON encoded FHIR content: Unrecognized token 'json': was expecting ('true', 'false' or 'null')\n at [Source: UNKNOWN; line: 3, column: 29]"
FHIR is the standard used. I also tested with a valid JSON that worked with Postman, so I don't think the actual JSON is the issue.
I'm not sure if I'm correct, but it seems JMeter adds 'json' from somewhere as the error states the token 'json' is unexpected. This is the Request > Request body tab in View Results Tree.
This is just a test JSON, but I got the same response with a JSON body that is working in Postman (and I formatted correctly to be sure). I have the Content-Type header specified. I simply don't understand where the token 'json' would come from as my json itself doesn't contain the token. Does anybody know if JMeter adds something to the request?
You're sending incorrect payload, it should look like:
{
"test" : "X"
}
and you are sending
{
"test" : "X"
}json
^^^^ this guy is causing the issue
JMeter doesn't add anything to request, you need to double check your configuration, i.e. JMeter jmx scripts are "normal" XML files so you can use your favorite text editor to look up this json
If you're able to send a valid request using Postman you should be able to record it using JMeter's HTTP(S) Test Script Recorder, just configure Postman to use JMeter as the proxy and run your request/collection - JMeter will capture the requests and generate relevant HTTP Request samplers which can be replayed successfully.
More information: How to Convert Your Postman API Tests to JMeter for Scaling
It happened to be that if you add a default parameter in an HTTP Request Defaults (in my case _format=json), it would add it to the body of the POST.
I fixed this by adding a BeanShell PreProcessor with the code:
if(sampler.getMethod().equalsIgnoreCase("get")){ sampler.addArgument("_format", "json"); }
I have been working on one of my projects using node and ng4
when I came across using res.json to send an array back to Angular 4 front end, like res.json(arrayResult). Surprisingly, I cannot use JSON.parse(arrayResult) after Angular receives it because it throws an error saying unexpected end of input. I however can access all the data through result[i], just like any normal array.
I don't quite understand why res.json() does not send my array as a string to the front end. Is there any internal conversion involved? Why I could access the content through index without even parsing it or doing any conversion with it?
The server indeed send your json data as a string. Additionally to the string, the server passes Content-Type header to your client which tells your client what kind of data you received.
So if the Content-Type was text/html your client would think that he received an HTML file.
In your case, res.json using Content-Type: application/json which tells the client that the string that he got is actually a json object, so no need for you to use JSON.parse.
You can see the Content-Type under the response headers property.
I am trying to publish a json message using the Amazonsns connector in WSO2 ESB 4.9. I am able to successfully publish a simple string message however when I set the messagestructure to json in order to send different messages to different platforms and attempting to send json as the value of message it will not work. I am using a simple transaction that looks almost exactly like the documentation sample. My Transaction:
content-type: application/json;charset=UTF-8
{
"region":"us-west-2",
"accessKeyId":"MyAccessKey",
"secretAccessKey":"MySecretAccessKey",
"version":"",
"messageStructure":"json",
"subject":"Test",
"message": {"default":"mess","email":"message"},
"targetArn":"arn:aws:sns:us-west-2:977102061874:endpoint/APNS_SANDBOX/mobile_iOS_Sandbox/34ed4324e6-1119-67sd-b7dd-f413c88e4e25",
"topicArn":""
}
My result is an unexpected error sending message out.
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,73]Message: Illegal character: <d>
My service is also like the example:
<amazonsns.init>
<region>{$ctx:region}</region>
<accessKeyId>{$ctx:accessKeyId}</accessKeyId>
<secretAccessKey>{$ctx:secretAccessKey}</secretAccessKey>
<version>{$ctx:version}</version>
</amazonsns.init>
<amazonsns.publish>
<message>{$ctx:message}</message>
<subject>{$ctx:subject}</subject>
<messageStructure>{$ctx:messageStructure}</messageStructure>
<topicArn>{$ctx:topicArn}</topicArn>
<targetArn>{$ctx:targetArn}</targetArn>
</amazonsns.publish>
I did not expect much success but just started trying different things....I attempted xml encoding the json message and get the same message on '&'. Using wire logs I found the content type of the successful messages going to Amazon were application/x-www-form-urlencoded so I also tried url encoding and get same message on the '%'.
I'm running out of ideas. I double checked the connector documentation to make sure I did not miss anything. It does say you can use a JSON transaction for Publish and gives a sample transaction however it does not discuss anything special/different that you would need to set up in order to make this work. Is there something I am missing?
UPDATE: Can see it is using the Builder for application/x-www-form-urlencoded which is stumbling on the json. Have tried setting messageType and ContentType properties to application/json. JSON Builder is enabled. It just seems the connector wants to send it out as application/x-www-form-urlencoded, is there something I am not setting properly to tell the connector this is JSON?
UPDATE: The publish template that comes with the connector is setting the messagetype to applicaiton/x-www-form-urlencoded which is overriding any of the settings I am making in my proxy service. Going to look at changing the template in the connector to use a different messagetype and/or allow me to set it in the proxy dynamically then will be trying again.
Joe
We have created a public JIRA for this issue. Please follow that.
You need to enable message builders for the content types you are sending. make sure following is done.
Enable relevent Message builder for each content-type.
< messageBuilder contentType="application/json"
class="org.apache.synapse.commons.json.JsonStreamBuilder"/>
Make sure Content-Type header property is parsing with the message.
Make sure your Json is wellformed.
I'm using $.getJSON and I get this error "Invalid character".
My server side returns a good looking json, and in fiddler I think it also looks fine.
What am I doing wrong?
Thanks.
You have a mix of XML and JSON in your response. This obviously does not work. It needs to be valid JSON only.
We are in the middle of a ongoing discussion about how to handle REST exceptions.
Response Content type : JSON
Two solutions we have:
Throw all the unchecked exceptions as a JSON response.
Send Request Invalid Response code.
Arguments:
When its a error, why return JSON? Just send a invalid response code.
Counter Argument:
Response code are too technical to handle for normal developers.
Whats your say??
For a JSON API I recently developed I do both. I always respond with valid JSON (well, assuming I respond at all). If I detect an invalid request, I use status 400. If I detect a server error (which I don't believe is caused by an invalid request), I use a 5xx status. The JSON object contains a special key that is only set for errors, with a string value.
I think this is a good solution that respects REST principles, and can be used in multiple ways. The same solution is used by some other JSON APIs, such as Yahoo Search. Try http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json .
Use error codes like for HTTP. So 50* for any exception cause by some internal problem. And 40* for bad arguments. Avoid using your own defined codes as far as its possible. The idea is to have a "uniform" interface.
In general.
204 for success without sending any content
200 for success with a json representation of the resource
And if its not a successful operation return appropriate response code. You can choose to optionally return a json. To simplify things you can have a common format (json) for all error responses.
http://en.wikipedia.org/wiki/REST is a must read before you freeze on your api specs.