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

[n0bin0bita]

最近比较闲在和家人开发一个自己使用的 web 应用，我写后端，她写前端。我是计算机专业毕业，但是毕业以后是运维岗，偶尔会自己写一些代码，都是比较简单，没有在正经后端开发岗位干过，都是随意写，自己明白就行。这几天关于接口返回内容的问题上突然有了一个疑问（基于因为前端代码问题需要修改响应的 json 结构），在实际工作中这个规范如果出现了前后端有分歧的地方，一般都是前端改（解析逻辑），还是后端改（响应结构）呢，当然实际工作中 可能 在项目一开始就有明确的定义之后再干活，但是我还是挺好奇，如果真的出现这个问题是有一个肯定的答案，还是说大家商量着来，还是咋样呢。

[hukei]

所以有 api 文档这种东西

[lonjin]

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

[NeedI09in]

怎么方便怎么来吧

[tianterrence]

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

[cxe2v]

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

[atangdev]

ResultAPI 了解下

[aababc]

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

[heybwei]

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

[wingzhingling]

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

[seanlin5]

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

[fruitmonster]

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

[aincvy]

@atangdev 您是不是要找：Restful API

[Lockroach]

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

[jiemiccllv]

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

[realJamespond]

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