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?
You may require to add Content-Type: application/json on API Gateway Integration Request body template mapping like this:
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.
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.
postman menu
Related
I want to hit a remote API using a post request. It's working fine with Python, but when it comes to my Knime workflow, the remote end is complaining that it can't find a needed parameter (type in the image below). What is the correct way to pass the post parameters in Knime? In Postman I would have a body tab for example to define everything I needed, but apparently I'm missing something in Knime.
I am writing a web service in node, and testing it with Postman. I spent a long timing looking for an error. When I finally found it, it turned out to be a simple error formatting the response body, which is json.
If I leave off the final brace in the response body, Postman waits for two minutes, and then reports that it received everything, just fine.
If I leave off the closing quote in the last value in the json, Postman says the server didn't respond, perhaps I should check my security certificates.
I would much rather Postman said "Hey, Buddy, you left off a quote!"
If there some validation service I can talk to? Or a plugin in Postman?
Here there are some validation javascript libraries, you can use:
Validator provides a declarative way of validating javascript objects.
Express-validator acts as an express.js middleware for node-validator.
Meanwhile, Postman got API testing and Collection Runner that can help you through this; which you can write some pre-request script as well as test script for each request.
Also, they got Newman which is a command-line collection runner. It allows you to effortlessly run and test a Postman collection directly from the command-line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.
I found that Paw worked (https://paw.cloud/). And so far I haven't paid for it.
Where Postman said "check your security certificates," Paw said "we were expecting 376 bytes but you only sent us 312."
Cuts down my time solving the problem a lot!
I use Fiddler for this. It is very good at identifying (with an error message that pops up) problems and bad implementations of the HTTP protocol. Browse the web with it running, and within a few minutes you'll undoubtedly hit a poorly implemented server.
Postman won't be able to handle these cases since it's insulated from poor behavior by the browser's framework.
That's not your problem though.
When I finally found it, it turned out to be a simple error formatting the response body, which is json.
That has absolutely nothing to do with HTTP. HTTP doesn't know or care what your request/response bodies are.
The problem you face is that your API endpoint could be returning whatever it wants. You need a custom solution to your problem, as there is no standard API server in this case.
Most folks will run unit tests that hit common endpoints of your service to ensure they're alive and well.
I should also point out that it should be all but impossible for you to break the JSON response if you're doing it correctly. Sounds like you're serializing JSON manually... never do that, we have JSON serializers for this purpose. Send in an object and let it worry about building the JSON output for you. Otherwise, you'll waste a lot of time on problems like these.
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.
Can anyone tell me if it is possible to specify mime-type returned from a RESTful web service through the URL? I am trying to demo a simple service that I created to someone and I am just using a web browser (Chrome) to invoke the service. I am trying things like this:
http://localhost:8088/providers?mimeType={application/json}
http://localhost:8088/providers?mimeType=application/json
http://localhost:8088/providers?mimeType=json
None of these work for me - I just keep getting XML returned no matter what I select.
I found several posts related to this subject, but nothing with an answer about how to do this through a URL (I found some which talked about setting headers, but I am using a browser and don't have the ability to specify headers). I found this post:
REST Content-Type: Should it be based on extension or Accept header?
And that post linked to this: http://www.xml.com/pub/a/2004/08/11/rest.html
On the xml.com site, I found this text:
URI-Specified Representation [PS, AR]
A client can specify the representation using the following query string:
mimeType={mime-type}
A REST server should support this query.
So it seems that what I am trying to do should be possible, but I can't figure out how to make it work. Can anyone help?
Thanks.
To define the headers added to your request, you can use a Chrome extension like Postman.
Then you will be able to specify an Accept header to tell Talend to return json:
Accept: Application/json
New here. I've searched quite a bit for a working solution to my problem, but even though I have found posts with promising titles, none of the solutions have worked.
I am deploying an MVC2 web app to a client's server.
I did my development on Win2k8 Server, but they are running Win2k3 sever.
The app's only purpose is to receive some record ID information as HTTP parameters, check in the database for the status of the given record or records, and then return the status information as a simple string such as "Completed" or "Incomplete" in JSON format.
This getJSON code works fine in the development environment.
Inexplicably to me, on the client's server, the getJSON request receives a null response from the application.
There is no cross-domain action AFAIK... the result is the same from the client's server or from my machine via VPN.
In the MVC model's Json code, a common solution for people is to add the "JsonRequestBehavior.AllowGet" attribute to the Json result being returned. I did this long before trying to deploy it, and as I said, it has worked fine in the dev environment.
Using Firebug, I have watched the same request URL get sent to both my local server and the client server - the response headers from both servers are the same, but the response content from my server is shown as:
{"Result":"No Data"}
Which is what I want.
There is literally no content shown in the response from the client's server..? But the request gets an HTTP 200 code and is recorded as a success in the reponse's status attribute.
The response header content type in both situations is "application/json"
But wait, there is more!
If I manually enter the request to each server in the Firefox nav bar, and hit enter, in both cases it responds with:
{"Result":"No Data"}
Which is what I want. So why can I get the result I want from the MVC app on the client's server only when I hand-enter the request URL in Firefox, but not from the Javascript code?
I have tried forcing different output content types ... using the jQuery ajaxSetup method...
$.ajaxSetup({
async: false,
dataType: 'text'
});
or
$.ajaxSetup({
async: false,
dataType: 'html'
});
and again wtih 'script', and 'json'. I also tried the conversion options such as 'text json' or 'html json' or 'json text' and so forth.
Some of the posts I'm reading, and my gut feeling, though, suggest the problem is not the jQuery code making the request that is at fault... I don't see how the same jQuery request point to a different server running the same app would suddenly cause that server to send back a 'null' value.
By null, I want to be clear... I mean nothing is sent. There is no {} or {null} or any sign of JSON... just blank whiteness of non-existence :P
Even if nobody knows the answer, I would love some input perhaps suggesting where I should focus my sleuthing ... client or server?
If the problem is the server, it seems hard to really know that the MVC stuff is running 100% on the IIS6 server, but in general it seems to work. I have a different MVC app running on the client server which responds to the virtual paths, and generally runs the same as on dev machine.
I have found one thing ... the request headers are somewhat different? The Request Headers sent to the IIS7 setup include an "X-Requested-With: XMLHttpRequest", "referrer" , and "cookie" field/value.
I could guess that the lack of the "X-requested-with: XMLHttpRequest" in the IIS6 request headers is a clue, but I do not see then how the same javascript code pointing at a different server can generate different request headers itself. So how else are those being generated?
The javascript is embedded in an ASP.NET page, btw.
Oooh.. frustration!
Thanks for any input.
Odd Progress ... apparently there is some sort of issue with IIS6 handling the query. Although I have not payed any attention to JSONP, a post elsewhere suggested that sometimes use the "&callback=?" parameter at the end of a .getJSON request URL would force it into GET mode and that worked frequently for problems getting data from the server. So I did that... and it did work, sort of. The proper {"Result":"No Data"} was returned in response to the request... which seems good. However, the way that the JSONP callback works, it generates its own script to do the calling and fetching and interpreting of the incoming JSON. In this case, it interprets the JSON to need a label which it does not have, thus an error is thrown "invalid label" ... there must be some way to hack things to just deliver the JSON, but the whole required use of JSONP callbacks suggests that the server configuration is wrong, right? Or why does it work without JSONP for IIS7 and not IIS6?
Despite my not liking the callback JSONP solution, it appears to work ok. The error is still returned about an invalid label, but that does not appear to stop the remaining javascript from running... and so the application is working with IIS6 now. I have not tested the fix of using the callbacks and JSONP against IIS7 yet, but I expect it will work well enough.
Here is a link to the discussion that lead me to my current solution. I do still hope to find a more elegant solution, however.
NeoWin.net
Are you certain that your App Extension Mappings are set up correct?
Follow this article for running MVC2 on IIS6 and ensure all the different configurations have been done, that's probably the first step before going further and investigating specifics.
I'm really inclined to believe it's related to HTTP Verbs.