前提
在前后端联调的时候总会牵扯到一个问题，就是参数的传递方式，GET请求就不说了，参数往url后面一拼，万事大吉。
然而一到POST请求的时候，花样就来了，后端童鞋跟你说，我这个接口在postman试过是没问题的，你content-type设置成我要的就行了,要是真这么简单今天咱也就啥也不写了。
今天就来聊聊设置不同content-type时，前端童鞋的参数设置方式，以及在http中是什么样的，以及后端是怎么接受的。
content-type的值非常非常多，有兴趣的去查一下 HTTP Content-type 对照表，我们今天只谈POST请求 request headers中的content-type
准备工作
前端: fetch; 字符集设置: charset=utf-8
抓包工具: charles; 浏览器: chrome
node服务: Koa; 后端: SpringBoot
简单封装post
export const post = (url: string, params: any, options: any = {}) => {
return fetch(url, {
method: 'post',
headers: {
...options.headers,
},
body: params
});
}
node服务
import router from './router/index'; // 路由配置，无关紧要
const Koa = require('koa');
const koaBody = require('koa-body');
const app = new Koa();
app.use(koaBody({
multipart: true
}));
app.use(async (ctx, next) => {
console.log(ctx.request.headers);
console.log('body', { ...ctx.request.body }); // 主要看一下打印出的body
ctx.params = {
...ctx.request.body,
...ctx.query
};
await next();
});
app.use(router.routes()).use(router.allowedMethods());
app.listen(3000)
text/plain
首先就是content-type什么都不设置时，大多数情况下(下面马上就有例外)都会被浏览器默认为 text/plain 将参数设置为纯文本的形式，浏览器也不会对其进行处理。实际中使用时基本也不会这样来用，可跳过
application/json
代码
设置一下Content-type: application/json
post('/api/post-application-json', JSON.stringify({
name: 'application',
content: {
value: 20,
names: ['zhang', 'li']
}
}), {
headers: {
'Content-type': 'application/json; charset=utf-8'
}
});
Chrome
charles
node后端
按照json格式就没啥问题
Jave后端
@Data
private class FormVO {
private Integer id;
private String name;
}
@RequestMapping(value = "/post-application-json", method = RequestMethod.POST)
public int createForm(@RequestBody FormVO form) {
Integer id = form.getId();
String name = form.getName();
return 1;
}
需要为form写定制的class 即FormVO
application/x-www-form-urlencoded
表单上传：数据被编码为名称/值对
传统使用form表单上传时，都会创建一个form
表单构建
action="/api/post-form-urlencoded"
method="post"
encType="application/x-www-form-urlencoded"
>
提交
chrome
charles
可以看出原始文本还是以键值对的形式
问题来了，当你不想写form时，但是后端又要求你用form表单上传时，该怎么构建参数呢
哈哈哈，就手动自己写键值对拼在一起！
手动构建form参数
post('/api/post-form-urlencoded', `id=2&name=wee`, {
headers: {
'Content-type': 'application/x-www-form-urlencoded; charset=utf-8'
}
});
因为键值对的value要求为string，如果有复杂结构，那就需要对复杂value先JSON.stringify一下
post('/api/post-form-urlencoded', `id=2&content=${JSON.stringify({ name: 'aaa' })}`, {
headers: {
'Content-type': 'application/x-www-form-urlencoded; charset=utf-8'
}
});
node后端
JSON.stringify过的字段都得再JSON.parse回来
Java后端
@RequestMapping(value = "/post-form-data", method = RequestMethod.POST)
public Object createForm(@RequestParam Map params) {
Object id = params.get("id");
Object name = params.get("name");
return name;
}
简单愉快，扩展字段也不用手动去写class
multipart/form-data
然后就到了这货了
multipart/form-data: 数据被编码为一条消息，页上的每个控件对应消息中的一个部分
这个也是表单上传，跟application/x-www-form-urlencoded有啥不一样呢，主要是这个更厉害一丢丢，他可以用于上传文件
表单构建
action="/api/post-form-data"
method="post"
encType="multipart/form-data"
>
提交
看起来和application/x-www-form-urlencoded 没啥不一样的
chrome
再看下chrome下，好像也没啥不一样的，除了Content-type
charles
然而再来看看charles下的原始信息
duang! duang! 差别在这呢，被编码成一个消息体了
手动构建form参数采坑
然后就到了踩坑的地方了，不写form表单怎么按这种方式上传呢
首先是参数设置，必须使用FormData来构建参数，别的都白扯，
然后设置Content-type吗，该踩的坑还是踩一下试试
const formData = new FormData();
formData.set('id', '2');
formData.set('name', 'zhang');
post('/api/post-form-data', formData, {
headers: {
'Content-type': 'multipart/form-data; charset=utf-8'
}
});
结果呢，Chrome下
发现跟上面chrome下不太一样， chrome也不给你处理了，服务器也不干了
Error: bad content-type header, no multipart boundary
仔细看看，才会发现原生form, content-type后面还有个boundary,
这玩意干啥的呢
分隔符 上面说过了，form-data会被编码为一条消息，那我怎么分隔开这个消息体，解析得到我想要的键值对呢，就是通过boundary，就是那个特别长的------WebKitFormBoundaryK1IM1NwdabR3WdrA
手动构建form参数正解
所以怎么生成boundary呢，很简单，就不设置content-type,浏览器会因为你的参数是FormData类型，自动为你添加
const formData = new FormData();
formData.set('id', '2');
formData.set('name', 'zhang');
post('/api/post-form-data', formData);
不上截图了，跟form表单一样的东西
node后端
JSON.stringify过的字段都得再JSON.parse回来
form表单的后端处理看起来还是一样的
Java后端
和application/x-www-form-urlencoded 一样
总结
application/json 对于前端来说 真香
form表单对于后端来说，两种无差别，也不需要构造class
以后跟你的后端小伙伴好好商量吧(大哥，用json行不行)
更多推荐
java content-type设置_POST请求时 content-type的设置以及参数传递
发布评论