The POST request described in this article is one of the most common HTTP request methods specified in the HTTP/1.1 protocol. The POST request method is commonly used to send data to the server (mostly to create updates), and this article discusses the four data submission formats commonly used by the POST request method.

Since HTTP/1.1 does not specify how a request should be encoded, in theory it is entirely up to the developer to decide what format the Body Body of the request should be, although in practice there are still several common encoding methods for submitting data (ecologically critical).

Note: In no particular order…

application/x-www-form-urlencoded

For browser-native form forms, this is the default if the encType value is not specified. In fact, most cases can use it, coding is simple and efficient, all aspects of support is very complete, such as major browser debugging tools, major package capture software, etc..

POST http://www.example.com HTTP/1.1 Content-Type: Application/X-www-form-urlencoded; charset=utf-8 key1=val1&key2=val2Copy the code

The basic request is similar to the above, the data is encoded in the form of key1=val1&key2=val2, and the key value pairs need to use URL Encode. The data submission format is the same as that of the GET Request, but the location is changed from the Request URL to the Request Body.

This format structure is simple, but for the case of deep data hierarchy, such as some complex hierarchical interface data, this method is a little inadequate. On the other hand, this method is not as efficient for uploading binary data (such as images, audio files, etc.), and is lost for non-ASCII data, so it cannot be used for uploading files.

Application scenario: This data submission format is recommended when the data volume is small and the data level is not deep.

multipart/form-data

Use this method when you need to submit files, non-ASCII data, or binary stream data. This request is similar to the following:

POST http://www.example.com HTTP / 1.1 the content-type: multipart/form - data; boundary=----WebKitFormBoundaryPAlLG7hJKNYc4ft3 ------WebKitFormBoundaryrGKCBY7qhFd3TrwA Content-Disposition: form-data; name="text"

demo
------WebKitFormBoundaryPAlLG7hJKNYc4ft3
Content-Disposition: form-data; name="file"; filename="demo.png"
Content-Type: image/png


------WebKitFormBoundaryPAlLG7hJKNYc4ft3--
Copy the code

The second line specified encoding the content-type for multipart/form – the data, and then generate a dividing line between a boundary – WebKitFormBoundaryPAlLG7hJKNYc4ft3 namely, Long and smelly is intended to avoid conflict with the Body content, which is used to separate different fields.

The Body is divided into multiple structure similar parts, each part begin with — a boundary, because of the request generated a boundary for WebKitFormBoundaryPAlLG7hJKNYc4ft3, So in the end is — — — — — – WebKitFormBoundaryPAlLG7hJKNYc4ft3. This is followed by meta-information that describes the content, including the field name and, if it is a file, the file name and file type. The empty line is followed by the field value. And when does it end? It ends with a –boundary.

This method is designed specifically for file upload scenarios, although you can also use this method to transmit normal data, it will undoubtedly increase the size of the packet (boundary still takes up a lot of space).

Application scenario: File upload.

application/json

There was no such thing as JSON before it became popular. There were no hard and fast rules about how to submit data, so after JSON became popular, especially because of its ability to express data structures, we are now familiar with it.

POST http://www.example.com HTTP/1.1 Content-type: application/json; charset=utf-8 {"name":"xfly"."age": 24, "hobby": ["x"."xx"."xxx"]}
Copy the code

Application scenario: The data structure is complex and the data level is deep.