现在在做一个前后端分离的项目,前端如果向后端传递数据可能会用JSON。以前前后端没有分离时,在@RequestParam注解里指定name可以方便地从请求中提取出想要的参数,而不是非得用一个实体类接收请求数据。如果要接收前端传来的JSON数据,可以使用@RequestBody注解,但是@RequestBody不如@RequestParam方便,不能指定要提取的参数,只能用一个实体类接收请求中的所有JSON数据。
接收请求中JSON数据(例如接收JSON中的operation的值),有没有像@RequestParam("operation")这样方便的注解呢?
你要是觉得@RequestBody 转化成实体类或者Map不方便,你可以自己写个参数解析器,自己玩自己的一套东西。如果你解析成一个一个参数的,那你有没有考虑过如果50个参数,你方法要长到什么程度
如果一个请求真的有50个参数,那自然应该用实体类接收。
我想讨论的情况是,如果有许多控制器方法只需要接收1~2个参数,也要用一个实体类来接收(如果又恰好这些方法对应请求的参数名字都不同),可能会造成实体类“爆炸”。
接收请求体的JSON数据不如接收请求的查询参数或表单参数方便。接收查询参数或表单参数可以选择用实体类,也可以用@RequestParam注解,但是接收请求体的JSON数据只能用实体类,自由受限了。
没考虑到可以用Map来接收参数,用Map就可以不用创建那么多实体类了,但还是不如@ReqeustParam方便
@Halloworlds: “如果有许多控制器方法只需要接收1~2个参数,也要用一个实体类来接收(如果又恰好这些方法对应请求的参数名字都不同),可能会造成实体类“爆炸”” 关于这个,你可以创建一个类,里面20个属性,操作同样东西的控制器用同样的入参对象,减少类。或者有些参数少,1-2个的很可能是GET方式你可以还用@ReqeustParam。是在不行还能自定义注解,自定义参数解析器。比如来个@CustomReqeustParam 从body中获取属性,也一样
@RequestBody 怎么不方便了,你将你的实体类 加上@RequestBody 你只想要operation,那就直接取就是了,其他参数为null而已,而且如果需求变了,需要好几个参数的时候,后端根本无需改动参数。多一行少一行代码的事哦
用@RequestBody接收JSON数据,对于前端传来的每种格式不同JSON,都需要定义一个实体类去接收,这可能会导致实体类“爆炸”。而用@RequestParam注解就没这个问题了。
@RequestParam可以用map接收