由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了。但是我客户端呢?请看如下

是的客户端用的网络请求框架默认指定了contenttype属性。标识我们是以json格式进行的请求。而用postman默认的是text/plain纯文本格式请求,所以服务端映射出来的对象的各个属性都是null了。以前还真的没有注意到过这个问题。

        谨以此做记录。如有错误,欢迎指正。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值