这是一个创建于 521 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近比较闲在和家人开发一个自己使用的 web 应用，我写后端，她写前端。我是计算机专业毕业，但是毕业以后是运维岗，偶尔会自己写一些代码，都是比较简单，没有在正经后端开发岗位干过，都是随意写，自己明白就行。这几天关于接口返回内容的问题上突然有了一个疑问（基于因为前端代码问题需要修改响应的 json 结构），在实际工作中这个规范如果出现了前后端有分歧的地方，一般都是前端改（解析逻辑），还是后端改（响应结构）呢，当然实际工作中 可能 在项目一开始就有明确的定义之后再干活，但是我还是挺好奇，如果真的出现这个问题是有一个肯定的答案，还是说大家商量着来，还是咋样呢。
 | 1 hukei 2024-05-11 17:31:14 +08:00 所以有 api 文档这种东西 |
 | 2 lonjin 2024-05-11 17:33:20 +08:00 个人认为，谁改不重要，重要的是 必须有规则。定好规则就行。 |
 | 3 NeedI09in 2024-05-11 17:34:51 +08:00 怎么方便怎么来吧 |
 | 4 ny562kPWNJK9g86f 2024-05-11 17:34:57 +08:00 按正规的做法时，先写出 API 文档，然后向前端反述，确认没有问题再进入研发。 |
 | 5 cxe2v 2024-05-11 17:35:15 +08:00 项目开始之初，就会选定一个通用的返回结构，其余都是在这个结构内进行改造，每次开发的内容如何返回，由双方约定，并以文档形式固定下来 |
 | 6 atangdev 2024-05-11 17:36:03 +08:00 ResultAPI 了解下 |
 | 7 aababc 2024-05-11 17:37:21 +08:00 做 app 后端的，期望做到能在不发版的情况下做到最大程度的灵活性。所以我们的业务逻辑基本都在后端，前端偏纯展示。甚至很多字体的大小，颜色都是后端控制。 |
 | 8 heybwei 2024-05-11 17:40:06 +08:00 作为一个前端业务仔，我一般都是默认为： 首先是后端要采用一个通用的返回结构，无论那个结构是什么风格；然后就是前端改。 |
 | 9 wingzhingling 2024-05-11 17:51:38 +08:00 via Android 很多东西确实前后端都能写（比如数据的预处理）。一般考量的点包括：代码性能、网络传输成本、数据存储成本、数据安全性等等。 至于接口需要更改的情况，主要考虑：开发效率、代码复杂度、后续维护成本等等。 |
 | 11 fruitmonster 2024-05-11 18:46:15 +08:00 看什么情况喽，后端每个接口一般输出的格式都是固定的，要是后端接口不仅只有你用，要服务很多人那就得前端改，因为不可能单独为你改相应格式，若前端是你媳妇，那没得商量，你改！ |
 | 13 Lockroach 2024-05-11 23:49:33 +08:00 小团队怎么方便怎么来 大公司就要定好规范，先沟通定好规范文档再实现 |
 | 14 jiemiccllv 2024-05-12 14:51:21 +08:00 一版来说后端业务返回的 Json 结构通常包括两部分，一个是此次请求的业务处理状态（处理成功或者处理失败,并且附带失败类型和原因），另外就是此次请求的业务处理数据（通常是业务处理成功的处理数据）。第一部分通常公司内部或者团队内部都是有明确规范的，一般不会有歧义，而第二部分是在每次版本迭代时，需要在技术评审之后确认的技术细节，一般情况下由后端给出结构然后前端进行校对，待 API 返回结构确认后才会进入真正开发，后续一般情况下不会对 API 结构进行较大的改动，当然也仅限于开发前期，如果到开发后期后端要对 API 改动较大的话，且会影响到开发进度，后端是需要担责的。 |
 | 15 realJamespond 2024-05-13 10:17:01 +08:00 不管啥后端，只要是 http 统一返回 swagger.json ，然后转成前端接口 |
Select Language