In 2017 versions of PhpStorm / WebStorm there is a REST client we can use to send requests and analyze responses.
By default, when I send a POST and use the easy form in the UI to create request params, the parameters are formatted as x-www-form-urlencoded
instrument=JPY&id=6
I want to send data as JSON. So I thought if I add the content-type: application/json header, the IDE would format the request params accordingly, but it doesn't.
Currently the only way I see to send stuff in JSON format is to craft the JSON myself and put it in the Request Body as Text section of the IDE
Am I missing an easy way to send JSON?
You're not missing it, it's not there yet. Please vote: https://youtrack.jetbrains.com/issue/WEB-17342
Related
I am writing rest api with Flask. One of my endpoints handles a post request. One field of the request JSON 'audio' is supposed to contain the BASE64 encoded PCM file (audio format). If save this field to a file, it is about 200KB.
It might be too big to copy and paste in Swagger or Postman for testing. Even worse with curl command. Is there any good way to test with really big JSON in the request.
I'd recommend a great tool called Insomnia. You can send point it to any file to send it as a HTTP request. You can change the Content-Type header to be application/json and select your JSON data file. Here's a screenshot of what the program looks like.
I can send this successfully using the Postman Chrome extension with RAW data as below. How do I to build a HTML form, with fields to input message/badge/status and POST the data?
POST /rest/push/msg HTTP/1.1
Host: api.appery.io
X-Appery-Push-API-Key: myKey
Content-Type: application/json
Cache-Control: no-cache
{"payload":{"message":"Rockets important message","badge":"1"},"status":"sent"}
You can't.
There are a few ways that a form can encode data, but JSON is not currently one of them. There is a proposal to change that, but I'm not aware of any browser implementation in the wild.
Aside from that, a regular form submission doesn't support the addition of custom request headers (such as X-Appery-Push-API-Key).
If you want to make that request from a webpage, you'll have to construct it using JavaScript and send it with the XMLHttpRequest object (which would be subject to the Same Origin Policy).
I are trying to consume an OData Service whose purpose is to takes search criteria and returns the search results. I m using ODataJClient java library to consume the service.
I wanted to know if the input search criteria can be passed in JSON format to the OData Service. The catch is when we use the GET request, we are limited by the character length while the POST request would actually create a new entity with the payload. Any suggestions on how can we send the JSON input ? Thanks in advance ...
If you want to communicate with Service with JSON format, try add the following in request headers:
Content-Type: application/json
Accept: application/json
I try to make a stress test with jmeter: i set up jmeter proxy to record navigation and everythings is ok.
I have some problem with a page wich has a json request called by javascript: using the jmeter proxy this request doesn't works.
With firebug I can see that the response of json request is
{"error":{"msg":"couldn't parse request arguments","code":590}}
It seems that jmeter proxy modify the parameter request.
With this error, I cannot use this page: any suggest?
Thanks
Aldo
JMeter isn't able to execute JavaScript, you'll need to construct the request manually. Perhaps you'll need to get some parameter(s) from page source via Regular Expression Extractor. Once you figure out correct request make sure that you'll add Content-Type header application/json via HTTP Header Manager
New Relic currently URL encodes the JSON payload of our webhooks. We correctly include the necessary header, however, I'm wondering if this is best practice - or if the JSON payload should be sent un-encoded (or even with some different encoding)?
It's more common to send JSON directly in the request body with a Content-Type header value of application/json. It's not entirely uncommon to do it the way New Relic does however. GitHub post-receive hook payloads are also encoded this way.
In some languages/frameworks it's easier to extract the JSON data from a parameter than from reading the entire request body since form parameters are automatically parsed out and easily referenced and in some cases reading a request body may involve some more elaborate stream parsing.
An example of that is PHP's syntax for extracting the entire raw request body:
$data = file_get_contents('php://input');
var_dump(json_decode($data));
Versus extracting from a form parameter:
$data = $_POST["payload"];
var_dump(json_decode($data));
For frameworks that easily expose the request body, this isn't as much an issue. Here's the example given from the GitHub docs for handling the hook with Sinatra:
post '/' do
push = JSON.parse(params[:payload])
"I got some JSON: #{push.inspect}"
end
If the JSON body were passed directly, this is what it would look like:
post '/' do
push = JSON.parse(request.body.read)
"I got some JSON: #{push.inspect}"
end
It's mostly just an aesthetic preference, there's no technical advantage to either. With the parameter, you do get the flexibility of sending multiple JSON payloads in a single request or the option to send additional meta data outside the JSON. I would suggest sending a list of JSON objects and including all the meta data in a top level wrapper if that's important to you. Something like this:
{
"notification_id": "akjfd8",
"events": [ ... ]
}
I personally prefer raw JSON bodies, but that's mostly because it makes debugging far easier on sites like RequestBin. Your screenshot does a great job of illustrating how unreadable JSON encoded into a form parameter is.
<rant>
Payloads should be the content type you say they are. If they are sending as application/x-www-form-urlencoded then that is what you should expect to find. The culture of using a Russian doll model of nested encodings is beyond stupid in my opinion.
If you want to send JSON send it as application/json. Is that really so hard?
</rant>