The new company, the separation of the front and back ends of the new work, recently renovated the old functions, communicated with the front end, and had a new feeling for http requests
The old interface uses (post) key-value pairs to pass parameters:
Background receiving method:
@RequestMapping("customizeChaProduct")
@ResponseBody
@Transactional
public Map<String, Object> customizeChaProduct(HttpServletRequest request, HttpServletResponse response) 。。。。。
Due to new requirements, it is necessary to pass an array of objects, the format is as follows:
[{"tabName": "1","showOrNot": "Y"},{"tabName": "2","showOrNot": "Y"}]
The technology used in the previous paragraph vue.js: There are two forms of parameter transfer: 1, param, 2, data
Because of the previously used param background to receive key-value pairs
The new data is in the form of data, which makes the background unable to access
My understanding of Content-type
content-type (content format)
The format commonly used in postman is as follows:
form-data、x-www-form-urlencoded、raw、binary
It is the multipart/form-data in the http request , which processes the data of the form into a message, which is separated by a delimiter in the unit of tags. You can upload both key-value pairs and files
a application/x-www-from-urlencoded , which converts the data in the form into key-value pairs, for example, name=java&age = 23
You can upload text in any format, you can upload text, json, xml, html, etc.
Content-Type:application/octet-stream , from the literal meaning, only binary data can be uploaded,
The HTTP protocol (RFC2616) adopts a request/response model. The client sends a request to the server, and the request header contains the requested method, URI, protocol version, and a MIME-like message structure containing request modifiers, client information, and content. The server responds with a status line containing the message protocol version, success or error code plus server information, entity meta information, and possibly entity content.
Usually an HTTP message consists of a start line, one or more header fields, a blank line that just ends the header field, and an optional message body. The HTTP header field includes four parts: general header, request header, response header and entity header. Each header field consists of a domain name, a colon (:) and a field value. Domain names are case-insensitive. Any number of spaces may be added before the field value. Header fields may be extended over multiple lines, using at least one space or tab at the beginning of each line.
Both request messages and response messages can contain entity information, and entity information generally consists of entity header fields and entities. The entity header field contains the original information about the entity. The entity header includes Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Etag, Expires , Last-Modified, extension-header.
Content-Type is a very important content in the returned message, indicating what MIME type the following document belongs to. Content-Type: [type]/[subtype]; parameter. For example, the most common is text/html, which means that the returned content is of text type, and the text is in HTML format. In principle, the browser will decide how to display the returned message body content according to the Content-Type.
Type has the following form
Text: text information for standardized representation, text messages can be in multiple character sets and or multiple formats;
Multipart: used to connect multiple parts of the message body to form a message, these parts can be different types of data;
Application: used to transmit application data or binary data;
Message: used to wrap an E-mail message;
Image: used to For transmitting static picture data;
Audio: For transmitting audio or sound data;
Video: For transmitting moving image data, it can be a video data format edited with audio.