Four common methods of POST submission data (Application/x-www-form-urlencoded,multipart/form-data,application/json,text/xml)

The HTTP request method provided by the HTTP/1.1 protocol has options,, POST, PUT, DELETE, TRACE, CONNECT. Where post is typically used to submit data to the server, this article discusses several ways to submit data in the post.

We know that the HTTP protocol is an ASCII code transmission, based on the TCP/IP Protocol Application layer specification. The specification divides the HTTP request into three parts: a status line, a request header, and a message body. This is similar to the following:

<method> <request-URL> <version><entity-body>

The protocol specifies that the data submitted by the POST must be placed in the message body (entity-body), but the protocol does not specify what encoding the data must use. In fact, the developer can completely decide the format of the message body, as long as the last HTTP request satisfies the above format.

However, the data sent out, but also the service side of the success of the analysis is meaningful. General Service-side languages such as PHP, Python, and their framework have built-in features that automatically parse common data formats. The server is typically based on the Content-type field in the request header (headers) to learn how the message body in the request is encoded and then parses the subject. So when it comes to the POST submission data scheme, it contains two parts: the Content-type and the message body encoding method. They are formally introduced below.

application/x-www-form-urlencoded

This should be the most common way of POST submission data. The native form form of the browser, and if you do not set the Enctype property, the data will eventually be submitted in application/x-www-form-urlencoded manner. The request is similar to the following (extraneous request headers are omitted in this article):

POST http://www.example.com HTTP/1.1Content-Type: application/x-www-form-urlencoded;charset=utf-8title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

First, Content-type is designated as application/x-www-form-urlencoded, and second, the submitted data is encoded in key1=val1&key2=val2 manner, and both key and Val are URL-transcoded. Most of the service-side languages are very supportive of this approach. For example, in PHP, $_post[' title ' can get to the value of title, $_post[' Sub '] can get a sub array.

Many times, when we use Ajax to submit data, it is also used in this way. For example, the Ajax,content-type default values for JQuery and Qwrap are "application/x-www-form-urlencoded;charset=utf-8".

Multipart/form-data

This is another common way of POST data submission. When we use a form to upload a file, the enctyped of the form must be equal to this value. Look directly at a request example:

POST http: //www . example.com HTTP /1 . 1 Content-type:multipart /form-data ; boundary=----Webkitformboundaryrgkcby7qhfd3trwa   ------ Webkitformboundaryrgkcby7qhfd3trwa content-disposition:form-data; name= "text"   title ------Webkitformboundaryrgkcby7qhfd3trwa content-disposition: Form-data; Name= "file" ; filename= "chrome.png" content-type:image /png   png ... content of chrome.png ... ------webkitformboundaryrgkcby7qhfd3trwa--

This example is slightly more complicated. First, a boundary is created to split the different fields, so the boundary is very long and complex in order to avoid repetition with the body content. Then the content-type indicates that the data is encoded in Mutipart/form-data, and what the boundary of this request is. In the message body, the number of fields is divided into several similar parts, each beginning with –boundary, followed by the content description information, followed by a carriage return, and finally the field specific content (text or binary). If you are transferring files, include the file name and file type information. The message body finally ends with a –boundary– mark. For a detailed definition of mutipart/form-data, go to rfc1867 to view it.

This way is generally used to upload files, the major service-side language for it also has a good support.

The two types of POST data mentioned above are natively supported by the browser, and the native form forms are supported in both ways at this stage. But as more and more Web sites, especially WebApp, use Ajax to interact with the data, we can define new ways of submitting data, which will bring more convenience to development.

Application/json

Application/json this content-type as response head everybody certainly is not unfamiliar. In fact, more and more people now use it as a request header to tell the server that the message body is a serialized JSON string. Due to the popularity of the JSON specification, in addition to the low version of IE, the major browsers are natively supported json.stringify, the service-side language has a function of processing JSON, the use of JSON will not encounter any trouble.

The JSON format supports much more complex structured data than key-value pairs, which is also useful. Remember when I was doing a project a few years ago, the level of data that needed to be submitted was very deep, and I was committing the data JSON serialization later. But at the time I was using the JSON string as Val, still in the key-value pair, to be submitted in a x-www-form-urlencoded manner.

The Ajax feature in Google's AngularJS, by default, is to submit a JSON string. For example, the following code:

vardata = {‘title‘:‘test‘, ‘sub‘: [1,2,3]};$http.post(url, data).success(function(result) {    ...});

The final send request is:

POST http://www.example.com HTTP/1.1Content-Type: application/json;charset=utf-8{"title":"test","sub":[1,2,3]}

This scheme allows for easy submission of complex structured data, especially for RESTful interfaces. The big grab kits, such as Chrome's own developer tools, Firebug, and Fiddler, will show JSON data in a tree-like structure, very friendly. But there are also some service-side languages that do not support this approach, such as PHP's inability to get content from the above request through the $_post object. At this point, you need to do it yourself: When the Content-type is Application/json in the request header, the original input stream is obtained from the php://input and then json_decode into the object. Some PHP frameworks have already begun to do so.

Of course AngularJS can also be configured to submit data using the X-www-form-urlencoded method. If necessary, you can refer to this article.

Text/xml

My blog mentions xml-rpc (XML Remote Procedure call) before. It is a remote invocation specification that uses HTTP as the transport protocol and XML as the encoding method. The typical XML-RPC request is this:

POST http://www.example.com HTTP/1.1Content-Type: text/xml<?xml version="1.0"?><methodCall>    <methodName>examples.getStateName</methodName>    <params>        <param>            <value><i4>41</i4></value>        </param>    </params></methodCall>

XML-RPC protocol is simple, function enough, all kinds of language implementation have. It is also widely used, such as the WordPress Xml-rpc Api, the search engine ping service and so on. In JavaScript, there are also ready-made libraries to support data interaction in this way and to support existing XML-RPC services. However, I personally think that the XML structure is too bloated, the general scenario with JSON will be more flexible and convenient.

Four common methods of POST submission data (Application/x-www-form-urlencoded,multipart/form-data,application/json,text/xml)