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

今天发生一个离谱的问题

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

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

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

争论开始了

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

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

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

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

类似这样

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

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

最后虽然也改成统一的了

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

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

有分页 GET /users/page 和无分页 GET /users 各一个接口不就行了吗

懒得争论 直接 rows || data

意思是，同一个接口，从有分页改成无分页，并且数据结构变了，还没有通知你，如果是这样，那肯定是后端的问题。 如果是两个列表接口，分别用于有分页和无分页，那这个正常。 我感觉你说的是情况一，后端的锅。

这个没有统一规范，根据具体需求来说。本身这个规范也是由前端后端协商好的，不是由任意一方认为应该怎么就怎样的。所以提前协商好就行。 但是根据描述，这里的问题应该是出现在之前工作，然后现在不工作了？这个按你描述后端也没动？框架几十年了都一样。所以这里应该还是有一方动了？？

就算判断一般也不用 key 来判断 要么就分接口 要么就请求的时候通过查询参数是否请求分页 要么就一律统一返回一个格式,limit 设置个特殊标记表示无限比如 -1 不过嘛...最终还是看你们自己的约定来处理

@lucasj 接口不是同一个接口，但返回数据的格式不一样，有的是 rows 有的是 data

@vampuke 这不奇怪吗，万一需要用 data 的时候，rows 也错误的返回不一样的数据了咋办

@ltaoo1o 是的，可能也是误操作改了啥，这个不清楚。但前端排错很麻烦，因为第一时间根本意识不到是 key 变了，看到有数据就检查一下一环了，后面的排错纯粹是浪费时间

@pike0002 确实没有统一的规范，但有些接口是 rows ，有些接口是 data ，甚至要前端做兜底判断，给我的感觉还是比较怪的 不是之前的工作，就是刚才发生的，兼职工作