Required Integer parameter 'listId' is not present、JSON parse error

目录

1. @RequestParam(value = "listId") Integer id：Required Integer parameter 'listId' is not present

1.1 原因

2. 将@RequestParam修改为@RequestBody：JSON parse error

2.1 原因

3. 将Integer修改为String

4. 将参数修改为一个实体类封装listId

5. 建议

6. GET和POST区别

---

POST请求接口，前端参数调用为post调用，即封装body调用（如下），出现异常。

{
  "listId": 123
}

1. @RequestParam(value = "listId") Integer id：Required Integer parameter 'listId' is not present

org.springframework.web.bind.MissingServletRequestParameterException: Required Integer parameter 'listId' is not present

@RequestMapping(value = "/updateXXX", method = RequestMethod.POST)
public JsonResult updateXXX(@RequestParam(value = "listId") Integer id) {}

接口请求url如下：

request url: http://XXX/updateXXX?listId=1

1.1 原因

GET把参数包含在URL中，POST通过request body传递参数。

@RequestParam接收的参数是来自requestHeader中，即请求头。@RequestBody接收的参数是来自requestBody中，即请求体。

因使用@RequestParam，所以接口请求url如上，但POST请求，所以会去request body里寻找参数值，所以会找不到参数。

 

2. 将@RequestParam修改为@RequestBody：JSON parse error

org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Cannot deserialize instance of `java.lang.Integer` out of START_OBJECT token

@RequestMapping(value = "/updateXXX", method = RequestMethod.POST)
public JsonResult updateXXX(@RequestBody Integer listId) {}

2.1 原因

@RequestBody是将post请求中content值转为一个整体对象。@RequestBody的解析有两个条件：

1. POST请求中content的值必须为json格式（存储形式可以是字符串，也可以是byte数组）；所以会出现JSON parse error

2. @RequestBody注解的参数类型必须是完全可以接收参数值的类型，比如：Map，JSONObject，或者对应的JavaBean。

所以Integer类型不能作为@RequestBody注解的参数类型

3. 将Integer修改为String

@RequestMapping(value = "/updateXXX", method = RequestMethod.POST)
public JsonResult updateXXX(@RequestBody String listId) {}

接口请求url如下： 

request url: http://XXX/updateXXX

swagger接口如下：

 

当前POST请求中content的值存储形式就是字符串，这样使用postman发起请求或者前端请求时，请求body就必须下方格式，不太直观，也不规范，所以不建议使用

{
    123
}

4. 将参数修改为一个实体类封装listId

最终使用当前方式

5. 建议

一般情况下，get请求参数使用@RequestParam；post请求使用@RequestBody

6. GET和POST区别

• GET在浏览器回退/刷新是无害的；而POST数据会被重新提交。

• GET产生的URL地址收藏为书签；而POST不可以。

• GET请求会被浏览器主动cache；而POST不会，除非手动设置。

• GET请求只能进行url编码（application/x-www-form-urlencoded）；而POST支持多种编码方式。

• GET请求参数会被完整保留在浏览器历史记录里；而POST中的参数不会被保留。

• 当发送数据时，GET 方法向 URL 添加数据，URL 的长度是受限制的（URL 的最大长度是 2048 个字符）；而POST无限制。

• 对参数的数据类型，GET只接受ASCII字符；而POST没有限制。

• GET安全性较差，因为所发送的数据是URL的一部分，参数直接暴露在URL上，所以不能用来传递敏感信息；而POST安全性较好，因为参数不会被保存在浏览器历史或web服务器日志中。

• GET参数通过URL传递所有人可见；而POST放在Request body中。

 

看到了有趣的说法：

GET和POST是什么？HTTP协议中的两种发送请求的方法。HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。

所以说：GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

 

GET和POST还有一个重大区别，简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，告诉服务端等一下会有数据过来，服务端响应100 continue，告诉浏览器我已经准备接收数据，浏览器再post发送一个data给服务端，服务器响应200 ok（返回数据）。

多发的那个expect 100 continue header报文，是由客户端对http的post和get的请求策略决定的，目的是为了避免浪费资源，如带宽，数据传输消耗的时间等等。所以客户端会在发送header的时候添加expect 100去探探路，如果失败了就不用继续发送data，从而减少了资源的浪费。所以是否在发送一个包取决了客户端的实现策略，和get/post并没什么关系。有的客户端比如fireFox就只发送一个包。