由contenttype引发的一次小错误_contenttype引发了-优快云博客

本文通过一个实际案例说明了在使用不同客户端调用同一服务端接口时，Content-Type设置的不同导致的数据解析差异。强调了正确设置Content-Type对于确保接口能够正确解析请求数据的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最近项目依然是在写服务端了，最近有写到服务端提供接口给客户端让其调用。

正如大家所知，我们一般在和服务器交互时候，所有的接口请求都会定义一个统一的规范，一般都是同一个实体，例如下面的一个类

public class GeneralRequestVo<T> implements Serializable{
    private static final long serialVersionUID = -8448288200887137838L;
    /**
     * 通用请求信息（这也是一个实体，是一些公共参数，例如手机型号，app版本号之类的）
     */
    private CommonRequestMsg comm;
    /**
     * token（标识登录有效期的）
     */
    private String token;
    /**
     * 请求参数（这个其实才是具体的业务参数，泛型指定）
     */
    private T body;
    
    public CommonRequestMsg getComm() {
        return comm;
    }
    public void setComm(CommonRequestMsg comm) {
        this.comm = comm;
    }
    public String getToken() {
        return token;
    }
    public void setToken(String token) {
        this.token = token;
    }
    public T getBody() {
        return body;
    }
    public void setBody(T body) {
        this.body = body;
    }
}

我们客户端所有请求都会把这样子一个实体给服务端。然后看下服务端接口定义如下：

@RequestMapping(value = "/test", method = { RequestMethod.POST, RequestMethod.GET})
    public Map<String, Object> test(@RequestBody GeneralRequestVo<Map> requestVo) {
        //具体的业务逻辑被我删除掉了，这里相当于直接返回了一个空的json串“{}”
        return new HashMap();
    }

然后我们ios的大哥为了简便直接用了postman模拟了网络请求，虽然接口可以请求到，但是@RequestBody出来的GeneralRequestVo对象的属性值都是null。然后我使用的是我自己的客户端请求的，然后这个对象的属性就是有值的。我俩的请求参数基本一致。但是为啥一个可以另外一个就是不可以呢？

后来发现是我们的请求头有区别了。他在postman里面请求的时候没有指定contenttype了。但是我客户端呢？请看如下