关于实际工作中前端 后端在接口响应体规范上的疑问

所以有 api 文档这种东西

个人认为，谁改不重要，重要的是 必须有规则。定好规则就行。

怎么方便怎么来吧

按正规的做法时，先写出 API 文档，然后向前端反述，确认没有问题再进入研发。

项目开始之初，就会选定一个通用的返回结构，其余都是在这个结构内进行改造，每次开发的内容如何返回，由双方约定，并以文档形式固定下来

ResultAPI 了解下

做 app 后端的，期望做到能在不发版的情况下做到最大程度的灵活性。所以我们的业务逻辑基本都在后端，前端偏纯展示。甚至很多字体的大小，颜色都是后端控制。

作为一个前端业务仔，我一般都是默认为：
首先是后端要采用一个通用的返回结构，无论那个结构是什么风格；然后就是前端改。

很多东西确实前后端都能写（比如数据的预处理）。一般考量的点包括：代码性能、网络传输成本、数据存储成本、数据安全性等等。
至于接口需要更改的情况，主要考虑：开发效率、代码复杂度、后续维护成本等等。

@aababc 我们也是，数据处理重在后端，文字信息都由后端某个字段控制显示

看什么情况喽，后端每个接口一般输出的格式都是固定的，要是后端接口不仅只有你用，要服务很多人那就得前端改，因为不可能单独为你改相应格式，若前端是你媳妇，那没得商量，你改！

@atangdev 您是不是要找：Restful API

小团队怎么方便怎么来
大公司就要定好规范，先沟通定好规范文档再实现

一版来说后端业务返回的 Json 结构通常包括两部分，一个是此次请求的业务处理状态（处理成功或者处理失败,并且附带失败类型和原因），另外就是此次请求的业务处理数据（通常是业务处理成功的处理数据）。第一部分通常公司内部或者团队内部都是有明确规范的，一般不会有歧义，而第二部分是在每次版本迭代时，需要在技术评审之后确认的技术细节，一般情况下由后端给出结构然后前端进行校对，待 API 返回结构确认后才会进入真正开发，后续一般情况下不会对 API 结构进行较大的改动，当然也仅限于开发前期，如果到开发后期后端要对 API 改动较大的话，且会影响到开发进度，后端是需要担责的。

不管啥后端，只要是 http 统一返回 swagger.json ，然后转成前端接口