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).
Related
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
I saw there are several related posts, but none really answered my questions.
To be specific, let's say there are some middle layers in front of the request handlers (e.g. web server, Spring framework, Jersey framework, etc). The request handler explicitly announced that it expects a JSON request.
Question 1 - if the client sends a valid JSON request, but set the content-type to be text/plain, is it valid situation for the middle layers NOT to deliver the request to the request handler because of the content-type?
Question 2 - if the client sends a valid JSON request and using content-type application/json, and the request handler announces that it will parse the JSON request by itself. Can I assume some real world implementations of the middle layers will still verify the request before passing it to the request handler? (in other words - is it valid to assume that application/json may cause performance loss?)
All application/json content is also valid text/plain, so I don't see how a middle layer validation could catch that. It doesn't make sense for it to reject the request, unless it knows the request semantics which is supposed to be the responsibility of the request handler. The opposite case would make sense, with a failure when sending plain text payload that's an invalid JSON document with application/json.
The middle layer may validate if the payload with application/json is valid, but to worry about performance loss at this point is pointless. If after profiling your application you realize that this validation is a bottleneck, then it's valid to worry about it.
I'm using nodejs and I want to make a unified handler to serve either JSON or HTML based on which one was requested from the client.
So far I though of simply passing a variable in the request body that I can check before serving
app.use(function(req, res) {
if (req.body.requested=='JSON')
res.json(...
else
res.render(...
But instead of passing the variable in request body, is there something in the headers or something intrinsically different between jQuery.getJSON() and jQuery.get() that I use to make the differentiation?
Yes, a better way is to simply check the Accept header of the request. For example, if the header says:
Accept: application/json
then it is appropriate to send JSON back. Or for example,
Accept: text/html
then you send back html.
I'd like to know if the POST method on HTTP sends data as a QueryString, or if it use a special structure to pass the data to the server.
In fact, when I analyze the communication with POST method from client to server (with Fiddler for example), I don't see any QueryString, but a Form Body context with the name/value pairs.
The best way to visualize this is to use a packet analyzer like Wireshark and follow the TCP stream. HTTP simply uses TCP to send a stream of data starting with a few lines of HTTP headers. Often this data is easy to read because it consists of HTML, CSS, or XML, but it can be any type of data that gets transfered over the internet (Executables, Images, Video, etc).
For a GET request, your computer requests a specific URL and the web server usually responds with a 200 status code and the the content of the webpage is sent directly after the HTTP response headers. This content is the same content you would see if you viewed the source of the webpage in your browser. The query string you mentioned is just part of the URL and gets included in the HTTP GET request header that your computer sends to the web server. Below is an example of an HTTP GET request to http://accel91.citrix.com:8000/OA_HTML/OALogout.jsp?menu=Y, followed by a 302 redirect response from the server. Some of the HTTP Headers are wrapped due to the size of the viewing window (these really only take one line each), and the 302 redirect includes a simple HTML webpage with a link to the redirected webpage (Most browsers will automatically redirect any 302 response to the URL listed in the Location header instead of displaying the HTML response):
For a POST request, you may still have a query string, but this is uncommon and does not have anything to do with the data that you are POSTing. Instead, the data is included directly after the HTTP headers that your browser sends to the server, similar to the 200 response that the web server uses to respond to a GET request. In the case of POSTing a simple web form this data is encoded using the same URL encoding that a query string uses, but if you are using a SOAP web service it could also be encoded using a multi-part MIME format and XML data.
For example here is what an HTTP POST to an XML based SOAP web service located at http://192.168.24.23:8090/msh looks like in Wireshark Follow TCP Stream:
Post uses the message body to send the information back to the server, as opposed to Get, which uses the query string (everything after the question mark). It is possible to send both a Get query string and a Post message body in the same request, but that can get a bit confusing so is best avoided.
Generally, best practice dictates that you use Get when you want to retrieve data, and Post when you want to alter it. (These rules aren't set in stone, the specs don't forbid altering data with Get, but it's generally avoided on the grounds that you don't want people making changes just by clicking a link or typing a URL)
Conversely, you can use Post to retrieve data without changing it, but using Get means you can bookmark the page, or share the URL with other people, things you couldn't do if you'd used Post.
http://en.wikipedia.org/wiki/GET_%28HTTP%29
http://en.wikipedia.org/wiki/POST_%28HTTP%29
As for the actual format of the data sent in the message body, that's entirely up to the sender and is specified with the Content-Type header. If not specified, the default content-type for HTML forms is application/x-www-form-urlencoded, which means the server will expect the post body to be a string encoded in a similar manner to a GET query string. However this can't be depended on in all cases. RFC2616 says the following on the Content-Type header:
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
A POST request can include a query string, however normally it doesn't - a standard HTML form with a POST action will not normally include a query string for example.
GET will send the data as a querystring, but POST will not. Rather it will send it in the body of the request.
If your post try to reach the following URL
mypage.php?id=1
you will have the POST data but also GET data.
Just wanted a clarification of the form content types:
application/x-www-form-urlencoded: This is where you can send params encoded with the url.
multipart/form-data: ??
I need to send a JSON in the post (so it would have the type: text/x-json, I guess).
So the question is, is multipart/form-data suitable for this purpose / is application/x-www-form-urlencoded better?
Also, would it be possible to send some params encoded in the url, and some data in the json?
It looks like people answered the first part of your question (use application/json).
For the second part: It is perfectly legal to send query parameters in a HTTP POST Request.
Example:
POST /members?id=1234 HTTP/1.1
Host: www.example.com
Content-Type: application/json
{"email":"user#example.com"}
Query parameters are commonly used in a POST request to refer to an existing resource. The above example would update the email address of an existing member with the id of 1234.
I have wondered the same thing. Basically it appears that the html spec has different content types for html and form data. Json only has a single content type.
According to the spec, a POST of json data should have the content-type:
application/json
Relevant portion of the HTML spec
6.7 Content types (MIME types) ... Examples of content types include "text/html", "image/png", "image/gif", "video/mpeg", "text/css", and
"audio/basic".
17.13.4 Form content types ... application/x-www-form-urlencoded This is the default content type. Forms submitted with this content
type must be encoded as follows
Relevant portion of the JSON spec
IANA Considerations
The MIME media type for JSON text is application/json.
multipart/form-data
is used when you want to upload files to the server. Please check this article for details.