关于今天给前端返回数据的结构的争论

今天发生一个离谱的问题

我是个前端开发，有一个列表接口，本来有数据，后面突然列表没了，前端逻辑没动过

我看了看接口，发现接口正常，里面列表数据都在，在控制台打印数据也都正常

最后打印列表字段 rows 发现是 undefined，这才发现列表数据的 key 变成了 data

争论开始了

后端反馈是有两种数据结构，一种是有分页一种是无分页

有分页的接口返回 rows，无分页的接口返回 data

后面甚至提出前端在响应拦截器判断一下，有 rows 的话拿 rows，没有的话拿 data

我觉得很离谱，在我的认知中，我认为后端返回的数据要保持一致性

类似这样

interface ResponseData {
    code: number
    data: Array | Object // 这里就大概表示一下可以是列表数组可以是对象
    total?: number // 需要的话返回
    message: string
}

争论半天后端大概意思是：“一般都是这样的，分页和其他查询结果有差异”、“没有必要改 不然看不出来 分页和部分也的区别了”、“你现在没数据了你能第一时间知道是接口改成不分页的了”、“这个框架都几十年了一直都是这样” ...

最后虽然也改成统一的了

但我我对这套说辞是：？？？

想请教一下大家，你们对接的数据结构也是不统一的吗？哪种方式更好呢？

@donaldturinglee 好嘞 👍

@imba97 下次多做点沟通试试, 向下兼容一下. 我习惯做了接口改动都和前端说一下, 让前端记得重新看一下文档

@wangritian 好像是误操作之类的改了，后端可能也不知道。但我想如果数据格式一致的话，顶多就是分页失效了，还好发现点。我找半天发现是 key 名字换了这不扯淡么

“有一个列表接口，本来有数据，后面突然列表没了” 这件事重要的不是定义成什么样，而是后端改了东西不告诉前端 你需要强调以后任何修改都必须先协商，至于改成什么样，建议照顾下没水平又脾气大的那方

@donaldturinglee 文档是有的，虽然更新不及时

@imba97 没有文档的前端兼职做起来是这样的, 全靠猜

@donaldturinglee 但你架不住像我这种，后端可能误操作改了啥，然后前端疯狂排错，最后发现 key 变了，排错排了个寂寞的情况

@lucasj 笑死，早晚都是屎山确实不假。我自己的项目我是尽量避免写成屎山，公司项目就没办法了。我之前其实接受了，但今天排这个错排的心累，做了一些无用功。新手也确实是新手，感觉学不完

我记得我做的时候无分页和有分页也是两个接口, 我会在文档上写清楚返回的数据结构该是什么样的, 以文档为准