HTTP 协议是以 ASCII 码传输,建立在 TCP/IP 协议之上的应用层规范。
规范把 HTTP 请求分为三个部分:状态行、请求头、消息主体。
协议规定,POST 提交的数据必须放在消息主体(entity-body)中,但协议并没有规定数据必须使用什么编码方式。
服务端通常是根据请求头(headers)中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码,再对主体进行解析。
所以说到 POST 提交数据方案,包含了 Content-Type 和消息主体编码方式两部分 。
application/x-www-form-urlencoded
application/x-www-form-urlencoded:是最常见的 POST 提交数据的方式,
浏览器的原生表单如果不设置 enctype 属性,那么最终就会以 application/x-www-form-urlencoded 方式提交数据,它是未指定属性时的默认值。
数据发送过程中会对数据进行序列化处理,以键值对形式?key1=value1&key2=value2的方式发送到服务器。 数据被编码成以 ‘&’ 分隔的键-值对, 同时以 ‘=’ 分隔键和值。非字母或数字的字符会被 percent-encoding。
**在axios中当请求参数为qs.stringify(data)时,会以此方式提交数据。**后台如果使用对象接收的话,可以自动封装成对象
优势: 所有浏览器都兼容。
问题:在数据结构及其复杂时,服务端数据解析变得很难
application/json
随着 json 规范的越来越流行,并且对浏览器支持程度原来越好,许多开发人员在请求头中加入 content-type: application/json application/json ,这样做可以方便的提交复杂的结构化数据,这样特别适合restful接口。
它告诉服务器请求的主体内容是 json 格式的字符串,**服务器端会对json字符串进行解析,json 格式要支持比键值对复杂得多的结构化数据。**这种方式的好处就是前端人员不需要关心数据结构的复杂度,只需要标准的json格式就能提交成功。当在 axios 中请求参数为普通对象时,POST 请求默认发送的是 application/json 格式的数据。 application/json 需要封装成对象的话,可以加上 @RequestBody 进行注解。
优势:是前端不需要关心数据结构的复杂度,后端解析方便。
问题:少数浏览器不兼容。