一文搞懂get、post传参

首先大概说明一下:

(1)@GetMapping一般都是通过url传参数。所对应的接口参数只能是用@RequestParam注解或者不注解,但是他也支持body传参。

(2)@PostMapping既可以通过url传参数,也可以通过body传json参数。所对应的接口参数可以有@RequestParam注解,也可以有@RequestBody注解,也可以没有注解。当没有注解时,实体接收只能拼接在url传参。

(3)不管是@GetMapping还是@PostMapping,除了@RequestBody注解对应的参数是通过json在body里面传参数外,@RequestParam注解和没有注解都是在url中传参数.

(4)用@RequestParam注解修饰的字段前端必须有对应的参数传过来,用@RequestBody修饰的类,前端至少要传一个空的json串,json串内容不一定需要和类对应,json串中只要有类的字段,后端的类就会从中取出对应的字段并赋值。

(5)对于类对象的参数,不管对于@RequestBody还是@RequestParam还是没有注解,前端不管传来多少个字段,后端的类对象只取类中包含的对象

一、@GetMapping

当我们使用@GetMapping注解时,我们传参方式一般来说都是拼接在url后面,如下Params参数会自动拼接在url后面。

(一)后台接参方式一(实体):

如下测试可以接收参数的方式:

url传参(这个必然的):

还有一种可以接收的,就是使用form-data传参方式:

(二)后台接参方式二(字符类型):

如下测试可以接收参数的方式:

url传参(必然可以接收):

body form-data也同样可以传参

(三)当然get请求也可以body传参,比如我们实体添加@RequestBody注解时,我们就可以以json格式进行传参了。

添加了@RequestBody可以接收参数的方式(其实@RequestBody就是json传参,所以只有一种方式可以接收,如下):

json传参可以接收,注意:使用了@RequestBody就必须有json数据传递,可以传空{}但不能不传,不然会报错!同理我们使用了@RequestParam也是必须有对应的参数传递。

顺便说一下@RequestParam的使用如下,具体到参数类型的字段

总结:get请求可以url传参也可以body(form-data和json)传参,json传参必须加上@RequestBody,其他的传参可以不需要任何注解。

但是这样不符合开发规范,当我们拼接的参数过多时,建议使用post或者put的方式进行接口开发,虽然 HTTP 协议本身允许在 GET 请求中包含请求体,但是在实际开发中,大多数框架和服务器都不会解析 GET 请求的请求体。因此,通常情况下,使用 @GetMapping 注解时,参数应该通过 URL 参数传递,而不是通过请求体传递。

二、@PostMapping

post请求一般来说都是放在请求体body中,当然也可以拼在url中,这样也不太规范。

(一)正常情况如下(@Validated是字段校验的注解可以忽略):

然后前端就以json格式传参就可以了。

(二)特殊情况,当我们不添加@RequestBody注解时

如下测试可以接收参数的情况:

url传参可以接收

body   form-data可以传参

(三)当我们使用字符类型传参时

经测试,form-data可以传,url也可以传:

总结:所以无论是get还是post,form-data是基本上加不加注解都可传递给后台接收。而加了@RequestBody就必须传json数据无论是get还是post请求。所以加不加注解,用那种方式传参都条条大路通罗马,值得注意的是要符合我们的开发规范就可以。

拓展:multipart/form-data : 需要在表单中进行文件上传时,就需要使用该格

  • 21
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
CAN(Controller Area Network,控制器局域网)总线协议是一种广泛应用于工业自动化、汽车电子等领域的串行通讯协议。其帧格式如下: <img src="https://img-blog.csdnimg.cn/20200925125252655.png" width="400"> CAN总线协议的帧分为标准帧和扩展帧两种,其中标准帧包含11位标识符,扩展帧包含29位标识符。在CAN总线上,所有节点都可以同时发送和接收数据,因此需要在帧中包含发送方和接收方的信息。 帧格式的具体解释如下: 1. 帧起始符(SOF):一个固定的位模式,表示帧的起始。 2. 报文控制(CTRL):包含几个控制位,如IDE、RTR等。其中IDE表示标识符的类型,0表示标准帧,1表示扩展帧;RTR表示远程请求帧,0表示数据帧,1表示远程请求帧。 3. 标识符(ID):11位或29位的标识符,用于区分不同的CAN消息。 4. 控制域(CTL):包含几个控制位,如DLC、EDL等。其中DLC表示数据长度,即数据域的字节数;EDL表示数据长度是否扩展,0表示标准数据帧,1表示扩展数据帧。 5. 数据域(DATA):0~8字节的数据。 6. CRC:用于校验数据是否正确。 7. 确认位(ACK):由接收方发送的确认信息,表示数据是否正确接收。 8. 结束符(EOF):一个固定的位模式,表示帧的结束。 以上就是CAN总线协议的帧格式。在实际应用中,节点之间通过CAN总线进行数据交换,通过解析帧中的各个字段,可以判断消息的发送方、接收方、数据内容等信息。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值