Common four types of post submission data (small sum) _php tips

The HTTP request methods specified in the HTTP/1.1 protocol are options,, POST, put, DELETE, TRACE, CONNECT. In which, post is generally used to submit data to the server, this article mainly discusses several ways of post data submission.

We know that the HTTP protocol is based on the 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. Similar to the following form:

<method> <request-URL> <version>
 
 

The agreement stipulates that the data submitted by POST must be placed in the message body (entity-body), but the agreement does not specify what encoding the data must use. In fact, the developer can completely determine the format of the message body, as long as the last HTTP request is sent to meet the above format.

However, the data sent out, but also the service side of the successful resolution makes sense. General Service-side languages such as PHP, Python, Java,. NET, and their framework, are built into the ability to automatically parse common data formats. The server side usually learns from the Content-type field in the request header (headers) How the message body in the request is encoded and then parses the body. In other words, Content-type specifies how the message body is encoded. Therefore, the POST submission data scheme is directly related to the Content-type and the message body two parts.

application/x-www-form-urlencoded

This is the most common way to POST submit data. The native form form of the browser, if the Enctype property is not set, the data will eventually be submitted in application/x-www-form-urlencoded (enctype POST default). The request is similar to the following (the irrelevant request headers are omitted in this article):

POST http://www.example.com http/1.1
Content-type:application/x-www-form-urlencoded;charset=utf-8
Title=test&sub%5b%5d=1&sub%5b%5d=2&sub%5b%5d=3

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

Most of the time, we use Ajax to submit data, which is also used in this way. For example, Jquery and Qwrap Ajax, content-type default values are "application/x-www-form-urlencoded;charset=utf-8".

Multipart/form-data

This POST method is also very common. When we use a form to upload a file, we must have the enctyped of the form equal to this value. Here is an 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 generated to segment different fields, and boundary is long and complex to avoid duplication with the body content. The Content-type then indicates that the data is encoded in Mutipart/form-data, and what the boundary of this request is. The number of fields in the message body is divided into a number of similar parts of the structure, each part is started with--boundary, followed by the content description information, then enter, and finally the specific content of the field (text or binary). If you are transferring files, also include file name and file type information. The message body finally ends with a--boundary--mark. For a detailed definition of mutipart/form-data, please go to rfc1867 view.

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

Both of the above POST data methods are natively supported by browsers, and the native form form is only supported in these two ways at this stage. But with more and more Web sites, especially WebApp, all using Ajax for data interaction, we can completely define new data submission methods and bring more convenience to development.

Application/json

Application/json this content-type as a response to the head everyone is certainly not unfamiliar. More and more people now use it as a request header to tell the server that the message body is a serialized JSON string. Because of the popularity of the JSON specification, the server-side language also has functions that handle JSON, except for the large browsers that are not in the lower version of IE, and there is no trouble using JSON.

The JSON format is useful for supporting structured data that is much more complex than the key value pair. Remember, when I was working on a project a few years ago, I needed to submit a very deep level of data, and I was submitting the data JSON serialization later. But at the time I was putting the JSON string as Val, still in the key-value pair, and submitting it in a x-www-form-urlencoded way.

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

var data = {' title ': ' Test ', ' Sub ': [1,2,3]};
$http. Post (URL, data). Success (function (result) {
...
});

The final request to send is:

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

This scheme makes it easy to submit complex structured data, especially for RESTful interfaces. The big grab kits, such as Chrome's own developer tools, Firebug, and Fiddler, will display JSON data in a tree-like structure, very friendly. However, some service-side languages do not support this approach, for example, PHP cannot get content from the above request through the $_post object. At this time, need to deal with their own hands: in the request header Content-type as Application/json, from the Php://input to obtain the original input stream, and then json_decode into objects. Some PHP frameworks are already starting to do this.

Of course Angularjs can also be configured to submit data using the X-www-form-urlencoded method.

Text/xml

RPC (XML remote Procedure call is a remote invocation specification that uses HTTP as the transport protocol and XML as the encoding.) The typical XML-RPC request is this:

POST http://www.example.com http/1.1
content-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, the function is sufficient, each kind of language realization has. Its use is also very extensive, such as WordPress XML-RPC Api, search engine ping service and so on. JavaScript, there are ready-made libraries that support data interaction in this way, and can support existing XML-RPC services well. However, I personally feel that the XML structure is still too bloated, the general scenario with JSON will be more flexible and convenient.

The above content is small to share with everybody common four kinds of post submit data way, hope everybody likes.