写在前面
最近因为公司业务需要，用到了vue，因此继续选择了axios这个请求库，不可避免的，和后端联调过程中，也是遇到了不少的问题，对于上一次踩得坑，可以查看：浅尝node-记一次vue结合axios参数提交问题。
这次的话，主要是搞清楚一些原理性的东西，以便于遇到各种情况，能够最正确的去处理。
场景1：
前端请求头：Content-type：application/x-www-form-urlencoded; charset=UTF-8;
使用qs 插件将post请求以序列化（key1=value1&key2=value2...）。后端必须以相关插件来获得数据。
注：此时为表单提交方式，并且接口不符合restful API风格设计。
场景2：
去掉请求头：Content-type,查阅资料发现，axios默认请求头为：Content-type：application/json，数据以json格式传递，正常来说，符合我们的设计风格。
注：此时采用ajax请求方式，接口符合restful API风格设计。
问题重现：
场景1：如果后端只支持json格式，我们联调测试为：415报错（其实我也是昨天第一次遇到这种错误）。后端单独写一个支持表单提交的接口测试，提交成功，并获得数据。
场景2：取消请求头后，返回跨域报错，后端添加请求头，例：
response.setHeader("Access-Control-Allow-Origin", "*");
请求头信息不具体讨论，如有需要，可自行查找。
（ps：同样返回跨遇报错，解决方案待定，后面补充上来，暂未和后端联调成功。）
下面开始正题，这个问题发生后，今天就查阅了相关文档，分析究竟是哪个环节出现问题，并且对以前懵懵懂懂的知识，做一个补充。俗曰：刨根问底。
请求方式
首先，我们暂且不谈其他请求方式，以post请求为例。
post请求最主流的两种提交方式：
- Request Payload方式（ajax请求提交）：
原生的AJAX请求头里设置Content-Type:application/json，或者使用默认的请求头Content-Type:text/plain;参数会显示在Request payload块里，参数在请求体以标准的JSON格式提交。 - form-data方式（表单提交）：
如果请求头里设置Content-Type: application/x-www-form-urlencoded，那么这个请求被认为是表单请求，参数在请求体以标准的Form Data的形式提交，以&符号拼接，参数格式为key=value&key=value&key=value...
3.请注意上面问题：使用form-data方式返回415错误（无跨域问题），使用ajax发生跨域问题错误。
查阅相关资料后发现：传统的表单提交方式不涉及到跨域问题，ajax提交方式才能涉及跨域问题。（ps：以前完全没注意这一块...）
后查阅跨域产生方式得出总结： - 传统的表单提交方式只需要发出请求就行，无需响应操作，因此，认为是合理的请求。
- ajax跨域问题，其实世界本无跨域，只是用的人多了，便有了跨域。请求其实是发送出去的，但是在响应时，被浏览器所拦截。因为ajax发起跨域后，是脚本来处理相关请求内容，因此才有了跨域。
总结
当我们明白了上面各个请求方式后，可以总结出相关的结论：
1.如果使用axios请求库，通过文档可知道，axios默认的请求方式为：request Payload方式。而我们使用qs插件，修改请求头为：Content-type：x-www-form-urlencoded方式，其实是将请求方式改为表单提交的方式来进行，因此，不会涉及到跨域问题。
2.如果使用axios默认的请求方式，对于post请求，其实会发一个options的预请求，如果成功了，才能正式的发起请求，因此，我推测，我们的场景2方式，可能就是options的请求未处理，导致一直报跨域错误。
（ps ： 等联调完成后，再更新相关结论）
以上结论非正式结论，只是自己的一点心得，如有错误，敬请指出，感激不尽！
ps:
以上内容仅为自己的学习过程，欢迎大家取其精华，丢其糟粕。若对以上内容有不同简介或看法，欢迎一起探讨。
企鹅号：1041415167 邮箱地址：zth1041415167@outlook.com
网友评论