如何确定请求格式

问题前景

最近在整理一个项目的相关接口时，发现原有的接口接收参数各式各样。与负责项目的前端对了一下，发现前端并没有维护一个全局性的请求模块，也没有
具体的请求规则。基本上只要开发业务的与前端商量好，能跑就行。这就经常性的带来一些问题----1.前端传参方式与后端接收参数经常不一致，增加了
沟通成本。2.前端传参方式与业务场景不一致，容易引起误解。

常见的前端请求传参方式

一个HTTP请求的格式如下：

请求方法

（1）GET方法

注意GET方法不要传参数在body里面

（2）POST方法

（3）其他方法PUT,DELETE（一般不推荐使用）

参数存放位置

（1）param

param中的参数会直接体现在请求url后面的字符串中。一般用作GET，PUT方法中的的业务请求参数传递。

（2）header

header中的参数会直接体现在HTTP请求报文中的请求头。一般用于除了一些Cookie，Content-Type常见字段，以及一些业务自定义的通用属性字段。

注意：不建议在header中传递具体的业务请求参数，header主要用来存放一些表示请求属性的通用字段

（3）body

header中的参数会直接体现在HTTP请求报文中的请求体中。一般用作PUT方法中的业务请求参数传递。body中的数据存在多种格式类型，一般建议项目
统一使用一种类型，非必要不要混用。这里的类型与header里面的Content-Type字段对应。

1----application/json（json数据格式，这里推荐大家统一使用这种。）

2----application/x-www-form-urlencoded（表单默认的提交数据的格式。）

3----multipart/form-data（文件上传使用。）

常见的Controller收参数方式

接收请求方法

@RequestMapping(路径)----不限方法

@GetMapping(路径)----限定GET请求

@PostMapping(路径)----限定POST请求

接收参数格式

（1）使用默认接收方法

示例：

@RequestMapping("test.do")
public Object sendCommentSms(VipCommentReq vipCommentReq) {
    return (Object) vipCommentReq;
}

这里spring框架会默认先读取param里面的信息，再读取application/x-www-form-urlencoded类型传的信息

（2）使用@RequestBody接收

示例：

@RequestMapping("test.do")
public Object sendCommentSms(VipCommentReq vipCommentReq) {
    return (Object) vipCommentReq;
}

这里读取请求的Body中的信息，并且类型默认为application/json

（3）接收整个Http请求对象，再从中获取具体信息

示例：

@RequestMapping("test.do")
public Object sendCommentSms(HttpRequest req) {
    return (Object) req.getHeaders();
}

第三种相当于接收整个HTTP报文对象，可以根据自己需要读取其中的信息。

注意请求方式与接收参数方式一定要对应，不对应可能出现报错，也可能接收对象为空

这里推荐大家优先使用前两种

推荐的传参接收组合（建议，具体根据公司业务以及统一规范来决策）

（1）简单的查询请求：例如查询一个资源

建议使用GET请求方法，参数加在param中。

（2）提交数据，涉及数据变动的请求：例如提交个人信息

建议使用POST请求方法，参数放在body中。

（3）需要对请求鉴权（对所有请求的筛选）

建议在请求时将token或者其他的凭证字段加在Header中，做一个拦截器统一处理。

禁忌点

（1)POST方法里面的参数格式一会使用application/x-www-form-urlencoded格式，一会使用application/json格式。

（2）所有方法都用GET或者POST。（有些公司会要求统一使用POST，说明公司人员开发不规范，乱用GET与POST，所以一刀切）

推荐大家的一款管理接口工具

（1）Yapi接口管理平台

按照业务需求将接口纳入Yapi管理，开发时，后端先在Yapi规范格式。前端根据后端规范进行传参。这个也是主流平台。

（2）postman

postman功能更全，更丰富。但是postman必须要下载客户端，没有Yapi的网页便捷。

切忌：千万不要口头约束或者想一个是一个，会给后续的开发带来困扰