005-Four common methods of POST submission data

1. HTTP request method

HTTP Method	RFC	Request has Body	Response has Body	Safe	idempotent	cacheable
GET	RFC 7231	Optional	Yes	Yes	Yes	Yes
HEAD	RFC 7231	No	No	Yes	Yes	Yes
POST	RFC 7231	Yes	Yes	No	No	Yes
PUT	RFC 7231	Yes	Yes	No	Yes	No
DELETE	RFC 7231	No	Yes	No	Yes	No
CONNECT	RFC 7231	Yes	Yes	No	No	No
OPTIONS	RFC 7231	Optional	Yes	Yes	Yes	No
TRACE	RFC 7231	No	Yes	Yes	Yes	No
PATCH	RFC 5789	Yes	Yes	No	No	No

2. Message Format

The client and the server communicate by sending a plain text (ASCII) message. The client sends a request to the server and the server sends a response.

2.1. Request message

• request lines (for example, get/images/logo.png http/1.1 , it requests a name from the server called /images/logo.png of resources ).
• The Request header field (for example,accept-language:en).
• Blank line.
• Optional message body .

2.2. Response message

• status lines, including status codes and reason messages (for example,http/1.1, which indicates a successful client request).
• The Response header field (for example,content-type:text/html).
• Blank line.
• Optional message body
  

3. Content-type Processing of POST request

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. 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.

3.1, application/x-www-form-urlencoded "default native"

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.
The Ajax,content-type default values for the general default jquery and Qwrap are "application/x-www-form-urlencoded;charset=utf-8".
Requestbody receive is not available in spring MVC, normal field receive

3.2, multipart/form-data "File transfer"

When uploading a file using a form, you must make the enctyped of the form 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 ------ webkitformboundaryrgkcby7qhfd3trwacontent -disposition:form-data; Name= "text" title -------disposition:form-data; Name= "File"; Filename= "Chrome.png" content -type:image/ ------webkitformboundaryrgkcby7qhfd3trwa--

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.

3.3, Application/json "recommended"

It acts as a request header, telling the server that the message body is a serialized JSON string. Due to the popularity of the JSON specification, the json.stringify is natively supported by browsers other than the low-version IE, and the service-side language has functions to handle JSON.

JSON format supports much more complex structured data than key-value pairs

POST http://www.example.com http/1.1content-type:application/json;charset=utf-8{" Title ":" "Test", "Sub": [[i]}

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.
In spring MVC, you can use Requestbody to accept

3.4, Text/xml "not recommended"

Xml-rpc (XML Remote Procedure call). 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.

005-Four common methods of POST submission data